I might try this (or Gokrazy) next time I have a raspberry pi appliance use-case https://infosec.exchange/@blitz/113042244233789060
@pwaring urgh my sympathies!
@RogerBW certainly the ratio of decent tech books to crap was very poor. And those that stood the test of time to those which quickly became redundant, perhaps an even worse ratio. (I remember buying a book on Ruby on Rails once, and the very first “hello world” example was broken within a year)
It’s been ages since I’ve been to one of Steve’s Debian BBQs but they’re fantastic fun and the community he’s sustained around them is incredibly welcoming. Corporate beer sponsorship! https://blog.einval.com/2024/08/30#2024party
I’m “subtweeting” here and not citing the author (don’t want a pile on or whip lash) but the following I really disagree with:
“30 years ago, learning to program was mostly with books. These days it's hard to read books but YouTube and other platforms are the way to go. 😳”
“30 years ago, learning to program was mostly with books. These days it's hard to read books but YouTube and other platforms are the way to go. 😳”
I got a surprise surgery today (today was the surprise, not the surgery); hopefully my last for a long while. Just recovering from the anaesthetic now. Like a hangover with no upsides. (Or maybe a hangunder: perhaps tomorrow will be a blast)
@jwildeboer @lobingera for real guarantee that a rip is good, imho one needs to compare against AccurateRip. Drive tricks improve assurance but offer no guarantees. On macOS, iirc, “xld” is a ripper which supports AccurateRip.
@grifferz @alexhudson this, combined with the recent kerfuffle on lkml about inappropriate patches in the freeze cycle, are really disappointing
So: I've left nginx as Internet-facing, purely reverse proxy; lighttpd was doing some private CGI stuff so I've reconfigured it to be LAN only. Apache it seems was superfluous (pulled in via smokeping, I've since added that to lighttpd)
@mart_brooks that was what motivated me to move my personal stuff to lighttpd 10 years or so ago: In particular the relative ease of configuring fcgi
@noodles I think I've now largely forgotten the intricacies of configuring apache, perhaps a skill I should have kept sharp
@algernon heh, that's a project too far at the moment :)
Nginx is the “main” one which is mostly a reverse proxy for containers. Apache is for smokeping. Lighttpd appears to be configured for smokeping too
I seem to have nginx, apache and lighthttpd on my NAS. Perhaps time for a cull. Which should survive?
@SuperDicq @drewdevault @newt @philbetts @rahulsiddharthan the grass is always greener and all that but I'd like to see a more BSD-like split between Debian the OS and everything else ("ports" in BSD parlance) and (hopefully) work on quality particulary for the OS bit.
@SuperDicq @newt @drewdevault @philbetts @rahulsiddharthan Flatpak is just one; there are others. It's nice you feel Debian has good quality control. I feel it suffers, precicely from trying to package the universe.
@SuperDicq @newt @drewdevault @philbetts @rahulsiddharthan not at all. we have a plethora of other repositories today. Flatpak etc etc
@newt @SuperDicq @drewdevault @philbetts @rahulsiddharthan IMHO, one (perhaps the only) valid reason to package .NET Core in Debian would be if something else wanted in Debian needed it. (And wrt this hypothetical downstream dependency, there's an open question about, what *should* go into the OS layer?)
@newt @rahulsiddharthan @drewdevault @philbetts @SuperDicq I agree with most of what you are saying, but I don't agree with the premise that Debian (or any other distro) should package up the whole universe at all. It was useful in the 20th century when bandwidth was scarce. Now it's wasted work imho