Microsoft was famous for testing the Mac version of Office on base model 60MHz PowerPC machines
They did the same for Windows 95: developers were given 386s with 4 MB of RAM to test on, because that was the minimum requirement for Windows 95. And in the end, it ran -- just about -- on those specs.
Test your product on a crappy laptop
161–170 of 321 posts
Re: Test your product on a crappy laptop
#162Re: Test your product on a crappy laptop
#163Any recommendations for a solid, representative crappy laptop? $100 xSomething Thinkpad off Ebay? Or is there something more representative of today.
T500/W500, 4GB of RAM. It's something like 13 years old, and ~$60. It can run almost every website that hasn't been web-dev'ed into oblivion. It balks at anything with memory leaks and inefficient CPU/GPU load. It can run YouTube/Facebook/Twitter (surprisingly, for the last). It can't run https://github.com/
Re: Test your product on a crappy laptop
#164There are three kinds of web developers: - Those who don't care about performance, as long as it loads within a few seconds on their own beefed up system on the LAN. This article is for them, and we can only hope they will listen. - Those who care about performance, and work for people who care. They are already doing great work (or are about to), producing those rare low-friction, high-speed, content-is-king sites w…
Re: Test your product on a crappy laptop
#165Re: Test your product on a crappy laptop
#166I ve always wondered why all computers don't have a "slow down" setting
They have, kind of, it's the energy save mode. On Linux, (besides GPU) you'd set /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq to cpuinfo_min_freq, for all $i. I always look for minimum (idling) CPU frequency in devices before buying them, but this info is almost never available. My laptop has a min freq of 800 MHz, but I would like to go even lower, to better test low performance devices and limit energy us…
While the cgroup approach is (like cpufreq) doable by poking around in /sys/fs/cgroup (you mkdir new directories to create cgroups), cgroup-tools makes it a tad more straightforward by making the steps less verbose. (Besides cgroup-tools, "unshare" and "nsenter" ship with util-linux and can issue the syscalls necessary to start a process in a given cgroup, which you can't do with pure bash.)
The setup is always the same - you create a new "cpu" cgroup (here named "cpulimit"), then configure CFS (completely fair scheduler, I think? I thought there were multiple schedulers... maybe this only applies if using CFS? I think CFS is the default everywhere) with a period and quota. I think the period is used to derive an internal tick rate. The quota is a fraction of the period and the ratio (yay you get to do the math yourself) represents how much CPU the task gets to eat. I think the ratio applies across all the CPUs. I have no idea what happens if you bring PID-level CPU affinity into the equation. Maybe you can select which CPUs are enabled for the cgroup, and the math applies to whatever's enabled. Haven't answered any of that yet. In any case:
# cgcreate -g cpu:cpulimit
# cgset -r cpu.cfs_period_us=1000000 cpulimit
# cgset -r cpu.cfs_quota_us=100 cpulimit
A fairly straightforward demonstration: in one terminal run # cgexec -g cpu:cpulimit yes | pv -l > /dev/null
while in another terminal rerun the last `cgset` with quotas of 1000, 10000, etc, and watch the output rate go up and down. (In this case 100 is a good starting value, but anything more complicated than printf(); in a loop will probably finish launching in 2023 if started with a quota of 100.)The nice thing is that the cgroup happily sits in the background until explicitly deleted (and systemd leaves everything it didn't create alone) and you can just poke at its values anytime. Network cgroups can probably do interesting fun things to traffic as well (oh yeah, network namespaces = discrete iptables/nftables per namespace).
Lastly, the cooling_deviceN entries are in /sys/class/thermal, and have cur_state and max_state. YMMV; setting cur_ to max_ may well take several minutes to undo (very much the case on older systems at least) - maybe try that on a throwaway-able session. :D (Think "Task Manager (Not Responding)"...)
Re: Test your product on a crappy laptop
#167> British soldiers in World War I were equipped with a Brodie helmet, a steel hat designed to protect its wearer from overhead blasts and shrapnel while conducting trench warfare. After its deployment, field hospitals saw an uptick in soldiers with severe head injuries. > Because of the rise in injuries, British command considered going back to the drawing board with the helmet’s design. Fortunately, a statistician p…
We apply this kind of thinking at work: early on we focused all our energy fixing user problems or adding features that were requested. We realised it is actually a small number of users who volunteer to report to us what's wrong or missing (outside of regular crash/feature tracking) - they are the ones that care enough to make an effort, and it's a small percentage. So we started campaigning to engage users we never…
Re: Test your product on a crappy laptop
#168I don't like the attitude calling them craptops. A Gigabyte of memory and 10 Mbit/sec are enough to meet 99.9% of the user needs for Web browsing. If sites were implemented in a resource-aware manner of course.
Instead of looking down at craptops I would look down at people introducing 4K and using many Gigabytes of memory for personal computing. Even worse making masses use it. It's irresponsible greed and short-sighted capitalism that ruins the planet.
Re: Test your product on a crappy laptop
#169I had a similar experience building a NAS on a SoC. Suddenly things like transport or at rest encryption are no longer perceived to be free but really limit your performance. First time I actually had to be concious about choosing appropriate ciphers and hashing algos and not just using defaults.
Also, I'm very curious what SoC this was.
Re: Test your product on a crappy laptop
#170Earlier quoted context omitted.
They did the same for Windows 95: developers were given 386s with 4 MB of RAM to test on, because that was the minimum requirement for Windows 95. And in the end, it ran -- just about -- on those specs.
Did later editions (e.g. 95b) still run on the 386? I remember running 95b on a Pentium 166 MMX with 32MB of RAM and even that was a challenge at times!