Posts

Showing posts with the label disk

Free Python web hosting wanted

I'm still considering which of these would be the most preferred for a beginner showing off talent: HelioHost unlimited CPU, RAM, MySQL, bandwidth, 500MB disk, 2 cron jobs/day PythonAnywhere 100sec/day prioritized CPU, 512MB RAM, 1 daily task, low bandwidth, Internet whitelist OpenShift 3 gears of 1GB disk and 512MB RAM each AlwaysData 64MB RAM, 1GB/month traffic, 10MB disk, non-commercial use only

Linux cures Windows driver problem

Installing a Huawei E352 HSPA+ dongle took ages under Windows. I had to abort it halfway through because I was running out of time. In retrospective, it was probably caused by a conflict with the previous modem's connection dashboard. I was shocked when I wanted to resume next time. Some time after inserting the device, the system asked for a .sys file from a driver disk. Neither modem worked anymore. As usual for this kind of dongle, no vendor download is available as the device itself contains all drivers on a virtual CD-ROM. However, that is only accessible before it's  switched to modem mode  by the parts already installed. Chicken and egg problem. Puppy Linux to the rescue! Thankfully, I had it on my USB flash along with DSL and SliTaz . The system loaded to RAM rapidly. I copied over the drivers from the modem to another USB flash. As a plaything, I enjoyed the command line and the responsivity, also browsing the web a bit over 3G. After rebooting to Windows, re...

Daily disk array spinup at 7:34

While it may sound like utter nonsense at first, on second thought maybe it really is: cron.standard: please provide configuration facility to avoid given filesystems Someone should really be thinking more about a serious reminder system. I've put together an iotop oneliner that logs disk actions with timestamps which pointed me to anacron. Daily mlocate updating was easy to reproduce and fine tune: simply add your HDD mount points to tho PRUNEPATHS variable of /etc/updatedb.conf . On the other hand, it took a few more attempts and many days in total to track down what causes the HDDs to still start up. When trying to further examine the issue by hand, /etc/cron.daily/standard didn't start them up on first look, perhaps because of caching. However, today after randomly testing things again, it finally did, which took me to adding CHECK_LOSTFOUND=no to /etc/default/cron . It's a pity though, that I'll have to use an alarm clock from now on.