dankwiki - recent changes [en]

MediaWiki

Dank — Mon, 08 Jun 2026 05:20:34 GMT

php-fpm

← Older revision		Revision as of 05:20, 8 June 2026
Line 1:		Line 1:
	I'm using the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki] software from the WikiMedia Foundation to power my wikis. MediaWiki is ~~written in PHP5, and thus precludes~~ the use ~~of a multi-threaded version of~~ [~~http~~://~~www~~.apache.org ~~Apache~~].		I'm using the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki] software from the WikiMedia Foundation to power my wikis. '''The following information is largely [[Debian]]-specific.'''

			==Use with Apache==
			By default (at least on Debian), MediaWiki's PHP is run within Apache's PHP module <tt>mod_php</tt>. This can only be safely run under the multiprocess [https://httpd.apache.org/docs/2.4/mod/prefork.html mpm_prefork] paradigm. To use the (generally superior) [https://httpd.apache.org/docs/2.4/mod/worker.html mpm_worker] or [https://httpd.apache.org/docs/2.4/mod/event.html mpm_event] modules, one ought employ [https://www.php.net/manual/en/install.fpm.php php-fpm], the PHP "fast process manager" (note that FastCGI is also a thing. I don't know much about it).

	==Installing MediaWiki==		==Installing MediaWiki==
	~~'''The following information is largely [[Debian]]-specific.'''~~
	* Have handy the administrator account/password for your MySQL installation.		* Have handy the administrator account/password for your MySQL installation.
	** I advise you to install MySQL ''before'' MediaWiki, not as a single <tt>apt</tt> step.		** I advise you to install MySQL ''before'' MediaWiki, not as a single <tt>apt</tt> step.

Wordlist

Dank — Fri, 05 Jun 2026 20:00:06 GMT

← Older revision		Revision as of 20:00, 5 June 2026
Line 1:		Line 1:
	use these words in daily speech, and you too can be a big asshole!		use these words in daily speech, and you too can be a big asshole!

			* soteriology - the theological study of salvation
	* cruciarius - one who is crucified		* cruciarius - one who is crucified
	* autothysis - suicidal altruism, when a eusocial animal explodes for the better of the hive		* autothysis - suicidal altruism, when a eusocial animal explodes for the better of the hive

Rescuing your Chrome history

Dank — Tue, 26 May 2026 03:02:53 GMT

← Older revision		Revision as of 03:02, 26 May 2026
(One intermediate revision by the same user not shown)
Line 3:		Line 3:
	has it really been over a year since i blogged here? sheesh.		has it really been over a year since i blogged here? sheesh.

	for going on a decade at least, Chrome (at least the debianized "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant <tt>User Data/</tt> subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database <i>in memory and on disk</i>, meaning your history becomes null ("what?" you ask. "how can it corrupt the database on disk if the disk is full?" that's a great question, one to which i'd like to know the answer. obviously it's editing something in-place, or reserved some space, but it definitely happens.) visited sites can't be seen, and new loads aren't recorded. this seems a pretty substantial bug, but i guess no PM in mountain view gives a shit. so it goes. i have no insight into the mysteries of Chrome development planning.		for going on a decade at least, Chrome (at least the [[Debian\|debianized]] "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant <tt>User Data/</tt> subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database <i>in memory and on disk</i>, meaning your history becomes null ("what?" you ask. "how can it corrupt the database on disk if the disk is full?" that's a great question, one to which i'd like to know the answer. obviously it's editing something in-place, or reserved some space, but it definitely happens.) visited sites can't be seen, and new loads aren't recorded. this seems a pretty substantial bug, but i guess no PM in mountain view gives a shit. so it goes. i have no insight into the mysteries of Chrome development planning.

	if you close chrome and start it again following this corruption, the database (<tt>History</tt> in the user folder) is helpfully recreated from scratch, aka permanently lost. this is not usually what you want.		if you close chrome and start it again following this corruption, the database (<tt>History</tt> in the user folder) is helpfully recreated from scratch, aka permanently lost. this is not usually what you want.
Line 15:		Line 15:
	# run <tt>sqlite3 /tmp/chrome-history < /tmp/chrome-history.sql</tt>		# run <tt>sqlite3 /tmp/chrome-history < /tmp/chrome-history.sql</tt>
	# run <tt>mv /tmp/chrome-history History</tt>		# run <tt>mv /tmp/chrome-history History</tt>
			# run <tt>rm /tmp/chrome-history.sql</tt>
	# start Chrome		# start Chrome

	you ought have the vast majority of your history. obviously you can and should replace the hardcoded filenames with <tt>mktemp</tt> invocations.		you ought have the vast majority of your history. obviously you can and should replace the hardcoded filenames with <tt>mktemp</tt> invocations. you ought write them to a directory that is not world-readable, unless you don't mind people being able to read your browser history.

	'''previously: "[[GT2025\|GT2025]]" 2025-04-17'''		'''previously: "[[GT2025\|GT2025]]" 2025-04-17'''

	[[Category:Blog]]		[[Category:Blog]]

Dankblog

Dank — Tue, 26 May 2026 02:15:01 GMT

Entries

← Older revision		Revision as of 02:15, 26 May 2026
Line 4:		Line 4:

	==Entries==		==Entries==
			* [[Rescuing_your_Chrome_history\|rescuing your Chrome history]], 2026-05-25, 2201 EDT
	* [[GT2025\|GT2025]], 2025-04-17, 1529 EDT		* [[GT2025\|GT2025]], 2025-04-17, 1529 EDT
	* [[A_case_study_in_full-stack_device_development:_the_dankdryer\|a case study in full-stack development: the dankdryer]], 2024-09-29, 2329 EDT		* [[A_case_study_in_full-stack_device_development:_the_dankdryer\|a case study in full-stack development: the dankdryer]], 2024-09-29, 2329 EDT

Rescuring your Chrome history

Dank — Tue, 26 May 2026 02:14:02 GMT

Dank moved page Rescuring your Chrome history to Rescuing your Chrome history Misspelled title

New page

'''[[Dankblog|dankblog!]] 2026-05-25, 2201 EDT, at [[Viewpoint|the danktower]]'''

has it really been over a year since i blogged here? sheesh.

for going on a decade at least, Chrome (at least the debianized "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant <tt>User Data/</tt> subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database <i>in memory and on disk</i>, meaning your history becomes null ("what?" you ask. "how can it corrupt the database on disk if the disk is full?" that's a great question, one to which i'd like to know the answer. obviously it's editing something in-place, or reserved some space, but it definitely happens.) visited sites can't be seen, and new loads aren't recorded. this seems a pretty substantial bug, but i guess no PM in mountain view gives a shit. so it goes. i have no insight into the mysteries of Chrome development planning.

if you close chrome and start it again following this corruption, the database (<tt>History</tt> in the user folder) is helpfully recreated from scratch, aka permanently lost. this is not usually what you want.

if you notice the problem has occurred (you'll typically get a "you need to free up space!" message in Chrome), take the following steps:

# change to the relevant subdirectory of <tt>User Data/</tt>, usually <tt>Default</tt>
# run <tt>sqlite3 History .recover > /tmp/chrome-history.sql</tt>
# close running Chrome processes
# clean up necessary space, you disgusting hoarder
# run <tt>sqlite3 /tmp/chrome-history < /tmp/chrome-history.sql</tt>
# run <tt>mv /tmp/chrome-history History</tt>
# start Chrome

you ought have the vast majority of your history. obviously you can and should replace the hardcoded filenames with <tt>mktemp</tt> invocations.

'''previously: "[[GT2025|GT2025]]" 2025-04-17'''

[[Category:Blog]]

Rescuring your Chrome history

Dank — Tue, 26 May 2026 02:13:43 GMT

Created page with "'''dankblog! 2026-05-25, 2201 EDT, at the danktower''' has it really been over a year since i blogged here? sheesh. for going on a decade at least, Chrome (at least the debianized "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant <tt>User Data/</tt> subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database <i>in memor..."

New page