Seirdy's recent activity
-
Comment on Linux (In)security in ~comp
-
Linux (In)security
10 votes -
Comment on Coverage is not strongly correlated with test suite effectiveness in ~comp
Seirdy LinkI felt this article misses the forest for the trees. Coverage isn't just for verifying correctness; it's useful for detecting API changes, eliminating dead code, and building a better...I felt this article misses the forest for the trees. Coverage isn't just for verifying correctness; it's useful for detecting API changes, eliminating dead code, and building a better understanding of program behavior.
From a comment I posted on lobste.rs:
I also find coverage extremely valuable for finding dead or unreachable code.
I frequently find that unreachable code should be unreachable, e.g. error-handling for a function that doesn’t error when provided with certain inputs; this unreachable-by-design error handling should be replaced with panics since reaching them implies a critical bug. Doing so combines well with fuzz-testing.
It’s also useful for discovering properties of inputs. Say I run a function isOdd that never returns true and thus never allows a certain branch to be covered. I therefore know that somehow all inputs are even; I can then investigate why this is and perhaps learn more about the algorithms or validation the program uses.
In other words, good coverage helps me design better programs; it’s not just a bug-finding tool.
This only holds true if I have a plethora of test cases (esp if I employ something like property testing) and if tests lean a little towards integration on the (contrived) “unit -> integration” test spectrum. I.e. only test user-facing parts and see what gets covered, and see how much code gets covered for each user-facing component.
-
Comment on What is something you've changed your mind about recently? in ~talk
Seirdy Link ParentSeconded. Official docs are underrated. The official Git book is the only tutorial you need, with manpages for reference and shell completion for quick lookups. For 90% of use cases, you'll be...Seconded. Official docs are underrated.
The official Git book is the only tutorial you need, with manpages for reference and shell completion for quick lookups.
For 90% of use cases, you'll be covered if you understand cherry-picking, bisect, the types of merging, and resolving conflicts. The knowledge it takes to do those operations also encompasses pretty much all the other important stuff.
Also, learning how to collaborate with patches rather than branches/merges is extremely helpful for contributing to a variety of projects (Linux, ffmpeg, everything on Sourcehut, and many others).
-
Comment on Misinformation about Permissions Policy and FLoC in ~comp
Seirdy (edited )Link ParentUpdated the reference to the other post. Edit: updated again (a few times); it's less finger-pointy now. I really need to be less quick to publishUpdated the reference to the other post.
Edit: updated again (a few times); it's less finger-pointy now.
I really need to be less quick to publish
-
Comment on Misinformation about Permissions Policy and FLoC in ~comp
Seirdy LinkLots of people have been spreading the often-unnecessary advice to add a Permissions-Policy response header to their sites to opt-out of Google’s FLoC, and some have been going so far as to ask...Lots of people have been spreading the often-unnecessary advice to add a Permissions-Policy response header to their sites to opt-out of Google’s FLoC, and some have been going so far as to ask FLOSS maintainers to patch their software to make this the default. When discussions got heated to the point of accusing webmasters who don’t implement these headers of being “complicit” in Google’s surveillance, I felt I had to write this.
Everybody: please calm down, take a deep breath, and read the spec before you make such prescriptive advice about it.
FLoC is terrible, but telling everyone to add a magic “opt-out header” in every situation conveys a misunderstanding of everything you need to know about the opt-in/out process.
-
Misinformation about Permissions Policy and FLoC
8 votes -
Comment on I like that the boat is stuck in ~life
Seirdy Link ParentIs there a name for this humorous style of repetitive, cheerful, repetitive writing? Especially with regards to generally negative news (oil spills, a naval jam, etc). Another example: Discourse...Is there a name for this humorous style of repetitive, cheerful, repetitive writing? Especially with regards to generally negative news (oil spills, a naval jam, etc).
Another example: Discourse on HTTPS from n-gate, one of my favorite websites. I don't entirely agree with it and it isn't as funny as "the front fell off" and doesn't have the same sort of microhumor as the OP, but it was an excellent read nonetheless.
-
Comment on A look at search engines with their own indexes in ~tech
Seirdy Link ParentI discovered Petal, Gowiki, Crawlson, Yisou, Seznam, and Apple Search through my own access logs. I'm sure more have hit my site, but only keep logs for three to five days (and only for certain...I think it'd be interesting to cross-reference your findings with an aggregate of webserver logs.
I discovered Petal, Gowiki, Crawlson, Yisou, Seznam, and Apple Search through my own access logs. I'm sure more have hit my site, but only keep logs for three to five days (and only for certain HTTP responses) and I don't plan on changing that.
Most spiders in my experience aren't for search engines, let alone publicly-available general search engines; they're for SEO services, adtech, or benign content scrapers that grab content for link previews or bookmarking services.
-
Comment on A look at search engines with their own indexes in ~tech
Seirdy Link ParentIt was originally designed for finding Android apps; however, it expanded to general search a few months ago. It continues to be mobile-first. I wouldn't directly use it for anything non-trivial...It was originally designed for finding Android apps; however, it expanded to general search a few months ago. It continues to be mobile-first.
I wouldn't directly use it for anything non-trivial given its obvious privacy issues and piles of JS, but I hope it can be incorporated into other privacy-respecting metasearch/proxy engines.
-
Comment on A look at search engines with their own indexes in ~tech
Seirdy Link ParentThat's just the tip of the iceberg; there are tons more that I didn't include because the list of Bing-based engines was just way too long.That's just the tip of the iceberg; there are tons more that I didn't include because the list of Bing-based engines was just way too long.
-
Comment on A look at search engines with their own indexes in ~tech
Seirdy LinkFeedback and additions are welcome. Currently contains 30 indexing search engines.Feedback and additions are welcome. Currently contains 30 indexing search engines.
-
A look at search engines with their own indexes
26 votes -
Keeping platforms open
9 votes -
WhatsApp and the domestication of users
12 votes -
Comment on Who's on the fediverse? in ~talk
Seirdy Link@seirdy@pleroma.envs.net (non-js link). It's part of the envs.net tilde. Been thinking of making my own site a Fedi and xmpp instance so I could be seirdy@seirdy.one for email, fedi, and xmpp.@seirdy@pleroma.envs.net (non-js link). It's part of the envs.net tilde.
Been thinking of making my own site a Fedi and xmpp instance so I could be
seirdy@seirdy.onefor email, fedi, and xmpp. -
Comment on AWS announces they will create and maintain an Apache-licensed fork of Elasticsearch and Kibana in ~comp
Seirdy Link ParentA better approach would be to make the software a complement of another product that isn't just hosting. Customization, training, consultation, migration, consultation, etc. can all help pay the...A better approach would be to make the software a complement of another product that isn't just hosting.
Customization, training, consultation, migration, consultation, etc. can all help pay the bills.
-
Comment on Becoming physically immune to brute-force attacks in ~comp
Seirdy Link ParentI'd previously stumbled upon that article, but decided not to include it since it focused on too many variables and took a less extreme approach (A 1-kg black hole? That's it?). This was before I...I'd previously stumbled upon that article, but decided not to include it since it focused on too many variables and took a less extreme approach (A 1-kg black hole? That's it?). This was before I added a "further reading" section.
Thanks for bringing it back to my attention; I added it to the "Further reading section. Diff.
-
Becoming physically immune to brute-force attacks
11 votes -
Comment on Anyone using a lightweight browser with Linux? in ~comp
Seirdy LinkMost "lightweight" browsers use a heavy engine like Blink, Webkit, or Gecko. Of these three. Webkit is the lightest. Lightweight browsers that use an actual lightweight engine: Netsurf: limited...Most "lightweight" browsers use a heavy engine like Blink, Webkit, or Gecko. Of these three. Webkit is the lightest.
Lightweight browsers that use an actual lightweight engine:
-
Netsurf: limited and experimental support for JavaScript, but otherwise renders quite well.
-
Dillo: very limited support for CSS, passable support for HTML5. No JavaScript.
-
Konqueror with KHTML: KHTML isn't packaged for as many distros anymore, and is the ancestor to Webkit. Very poor JS support, but decent support for HTML/CSS. Can switch to QtWebengine (based on Blink) for sites that break in KHTML.
-
Links: has a graphical mode with
-g. No support for CSS, poor text rendering. -
hv3: uses tkhtml. I haven't used this one, but it seems slightly better than KHTML.
Edit: also, obligatory "f1rst p0st!!1"
-
I love using Linux on the desktop for many reasons despite its insecure architecture. This article from a Whonix developer and GrapheneOS contributor explains how Linux is behind when it comes to (mostly desktop-oriented) exploit mitigations.
Other articles worth checking out on madaidan's site take a critical look at Firefox and OpenBSD. He also has a good Linux hardening guide.