em-bee

most of those people were likely a bit older, already retired, and were out watching their grandchildren. sunday there is no school or kindergarten.

i actually had a situation recently where i wanted to delete a file that a process had open because i needed to free up space.

i had a process that wrote a massive log file (200GB) filling up the disk. i didn't want to kill or restart the process, but i needed to remove the log somehow. there was no log rotating option without killing the process. and i knew that just removing the file would not work, so instead i did "echo -n > logfile" causing the file to be truncated.

since the process still had the file open for writing it kept writing to the position it had written to last, creating a 200GB sparse block of virtual zeroes. not exactly what i wanted, but in hindsight, not surprising, and it did solve the problem of freeing up 200GB of space.

except this morning, a few weeks after i truncated the file the space was gone again, and the file was now 400GB large. how did those 200GB come back? and where even did they come from? it is not another sparse block, it actually has data (maybe junk data, but not all zero)

it is unlikely that the process wrote 200GB of logs in two weeks. the other 200GB were written over 2 years. i have yet to analyze what that data is. so far i only confirmed that it isn't all zero (by using cp --sparse=always, ensuring that all zero blocks would be made sparse which would then be easy to detect) (further cursory inspection suggests that the process did in fact write 200GB of logs in two weeks. the error being "Failed to bind socket". i wonder if that was caused by the disk being full the first time around.)

TL;DR: if you need to free up space from a file opened by another process then truncating works, but beware of side effects.

you mean they care about the product...

so, again, how is /e/OS being behind on updates any worse than fairphone's own OS?

it sounds like they are saying that /e/OS is less secure than fairphone's own OS. with all criticism against /e/OS taken into account, i highly doubt that fairphone would have been able to make their own version of android more secure than /e/OS when they are not even interested in working on that.

so sure, each case is different, and you are not wrong, but you are putting to much value on good institutions. the heavy lifting still comes from the parents. your children are doing well because you care that they do.

but that either applies to GrapheneOS as well, or there actually are trustworthy alternative ROMs out there. GrapheneOS being one, /e/OS being another, for example.

there are more that i am less familiar with, so i can't talk about them, but /e/OS is run by Gael Duval, who has been running a Linux distribution before that for many years. and even tough there are criticisms against /e/OS including the claim that it overstates its security and supposedly hasn't removed all google connections, i will trust Gael based on his reputation far above anything coming from google. even more so compared to other OEMs who stuff their android versions with bad apps that you can't remove.

so no, i am not trusting a random guy on the internet. i am trusting someone with a known reputation, someone who i have actually exchanged private messages with, someone who i could even meet in person if i were to come to the right conference.

so yeah, i totally want a wireless TV screen that is able to connect with all the devices in my house. but it's kind of difficult to achieve that without letting the TV access the internet. (not all home routers do not support blocking internet access to specific devices, and most people would not know that's how to do it)

in germany on the other hand, there was a case where parents demanded a school bus for a 7yr old, but the court said the kids could take the public train to school on their own.

this takes time to learn of course. and individuals handle this differently. i to can't handle interruptions, but when i am focusing a piece of code, and my partner telling me or asking me something about that same piece of code, then for me that's not an interruption. interruptions are notifications and being asked to change the focus on something different. that should not happen when pair programming.

another aspect not mentioned yet, when there is an actual interruption from the outside, one of the people in the pair can handle that interruption, while the other continues to focus. the interrupted one can then jump back in much faster than you would if you were interrupted while alone.

(we are nitpicking the nitpicking, it's nits all the way down. my last line in the previous comment was also based on the image. to shatter your steelman, picking on the illustration of the article that is just there to add some color is at best like a code review complaining about style or indenting. with endless bikeshedding opportunities, not something a code review should be focusing on. if the picture were of central importance then that would be different. btw, i am not complaining, i am having good natured fun here)

4 hours of pair programming per day can therefore possibly be enough to make up for the increased loss of performance in the rest of the day.

just drink a cup of NO and you'll be fine.

also if pair programming means saving time on code reviews then that's a further increase in velocity.