Seems like that'd be a good match for this place: https://www.bbc.com/travel/article/20260402-the-floridian-beach-town-that-looks-like-santorini
- Posts
- 4
- Comments
- 240
- Joined
- 3 yr. ago
- Posts
- 4
- Comments
- 240
- Joined
- 3 yr. ago
I only discovered "sink plungers" in the last year, and they've been remarkably effective for my uses. What usually ends up happening is that the blockage is brought up into the sink, at which point I vacuum it out with a wet-dry vacuum.
To be effective, the emergency drain hole of the sink needs to be plugged first, and then the plunger can do its work. Note: things will get gross and messy. Don't attempt if there is still drain cleaner in the pipes, since it will spray out.
Good heavens, that's impressive! The last Wii endeavor I heard of was making a Wii into a web server: https://infosec.exchange/@alexhaydock/114377262481451962 . It's still online!
Your original post was in c/linuxmemes , found here. Your follow-up question about phone security was a comment under that post. Although someone passing by might happen to be a senior pentester with a major mobile OS vendor, that is a community for posting funny memes.
To ask the commenters at-large there for a detailed, well-elucidated answer to "how does phone hacking work?" is to expect too much.
Fortunately, this is Lemmy so you just have to find the right community to ask, and to set your expectations accordingly.
That ebook reader is wild! Does the text stay in place while you read, or does it scroll past like a stock ticker?
If the latter doesn't exist, I guess I should go push a PR to make that happen on meshcore firmware haha
Hi! Firstly, thank you for using /dev/urandom as the proper source for random bytes.
Regarding the static H1-H4 issue, does your repo have any sort of unit tests that can verify the expected behavior? I'm aware that testing isn't exactly the most pressing thing when it comes to trying to overcome ISP- and national-level blocking. But at the same token, those very users may be relying on this software to keep a narrow security profile.
To be abundantly clear, I'm very glad that this exists, that it doesn't reinvent the WireGuard wheel, and that you're actively fixing bug reports that come in. What I'm asking is whether there are procedural safeguards to proactively catch this class of issues in advance before it shows up in the field? Or if any are planned for the future.
Ok, I'm curious as to the DPI claims. Fortunately, AmneziaWG describes how it differs from WG here: https://docs.amnezia.org/documentation/amnezia-wg/
In brief, the packet format of conventional WireGuard is retained but randomized shifts and decoy data is added, to avail the packets with the appearance of either an unknown protocol or of well-established chatty protocols (eg QUIC, SIP). That is indeed clever, and their claims seem to be narrow and accurate: for a rule-based DPI system, no general rule can be written to target a protocol that shape-shifts its headers like this.
However, it remains possible that an advanced form of statistical analysis or MiTM-based inspection can discover the likely presence of Amnezia-obfuscated WireGuard packets, even if still undecryptable. This stems from the fact that the obfuscation is still bounded to certain limits, such as adding no more than 64 Bytes to plain WireGuard init packets. That said, to do so would require some large timescales to gather statistically-meaningful data, and is not the sort of thing which a larger ISP can implement at scale. Instead, this type of vulnerability would be against particularized targets, to determine if covert communications is happening, rather than decrypting the contents of said communication.
For the sysadmins following along, the threat of data exfiltration is addressed as normal: prohibit unknown outbound ports or suspicious outbound destinations. You are filtering outbound traffic, right?
Because of the AI-induced scraping traffic? While not perfect, Anubis and similar are coarse-but-effective solutions for self-hosting repos.
And if it it were acceptable to outsource such protection to a CDN (eg Cloudflare) in order to retain firm control over the repo, then that's a choice that's also available. Not everyone agrees that CDNs have a role in self-hosting -- fair enough -- but when a project's very repo and existence can be wiped off the internet, owning a domain name and the affirmative upstream repository is a tractable and intermediate goal, even if it doesn't achieve full independence.
Self hosting is an exercise in harm reduction.
I'm of the opinion that hashtags are one of the most egalitarian things recently devised, because they require no advanced arrangements to use, can be created by anyone, can by adopted by everyone, and are amplified solely by their enduring usage. It is very much a popularity contest if a hashtag comes into vogue or if it is abandoned and something else is used, or maybe the specific community isn't as large as imagined. So for any given hashtag, I'd say just try it and see if it sticks. The Internet Police will not issue citations for improper hashtag use.
As for the underlying exercise of inviting LinkedIn people to break into your homelab, I'm not sure I see their incentive to do so. Why would unsolicited people (as in, not the AI bots) have any interest in doing so? If they had the chops to break into a network, why expend that time and effort for bragging rights, when instead that sort of work is billable?
As a general rule, I'm not thrilled when there's an implicit assumption that other people's labor is being valued at $0.00/hr. There's a fine line where it might be OK to ask an expert for a bit of help or advice, but the premise of your request is to get pentest professionals to do work for no compensation, and it's not even for a charitable, educational, or otherwise enriching purpose. Why should they?
I'm reminded of the email exchange referenced in this blog post, where an "unbreakable" encryption scheme is presented to an audience of highly capable cryptographers, and they proceed to demolish the scheme as being wholly broken, because the person who presented it could not take no for an answer. Do not be like this person.
TIL the EAS broadcast on WX band doesn't include a digital sub carrier with a text version of the audio warning. That's an amazing omission, since even the nationwide timekeeping signal out of Colorado has both an audio and digital mode.
That is an opinion, but certainly isn't settled law in any jurisdiction. Indeed, the answer to whether some, all, or none of an LLM's output is ever copyrightable and under what terms is the billion dollar question.
A project that incorporates code with shaky legal foundation will find it tough to convince others to contribute, if it's possible one day that their contributions were in vain. The right answer would be to extricate such code upon discovery, like what OpenBSD had to do when the IPFilter license turned out to be incompatible with the project.
If your patching an external library, please try to do what you can in the moment to formulate the patch in such a way that the upstream can accept it.
without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others
From the perspective of a user, why would they care about development speed? A user, by sheer definition of wanting to use the software, can only use software that is already developed. If it's not actually developed yet... they can't use it. So either they see the software at the end of the development cycle, or they never see it at all. Development speed simply isn't relevant to a user at that point. (exception: video games, but I'm not aware of any desktop game developed using a web framework)
As for platform consistency, again, why would the user care? Unless each user is actually running the same software on multiple platforms (ie a Windows user at work, Arch at home, and BSD at their side-gig), this is a hard sell to get users to care. A single-platform user might never see what the same software looks like on any other platform. Even mobile apps necessarily differ in ways that matter, so consistency is already gone there.
What I'm getting at is that the concerns of developers will not always be equally concerning to users. For users to care would be to concern themselves with things outside of their control; why would they do that?
Obligatory links:
Falsehoods that programmers think about dates and times: https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
Tom Scott descends into time and timezone madness: https://www.youtube.com/watch?v=-5wpm-gesOY
I've personally never worked with ISO 8601 directly, and quite frankly prefer how RFC 3339 simply doesn't deal with weeks at all.
Was this question also posted a few weeks ago?
In any case, what exactly are the requirements here? You mentioned encrypted journaling app, but also gave an example of burning a handwritten sheet. Do you need to recover the text after it is written, or can it simply be discarded into the void once it's been fully written out?
If encryption is to protect the document while it's still a draft, then obviously that won't work for handwritten pages.
128 MB (1024 Mb) of RAM, 32 MB (256 Mb) of Flash
FYI, RAM and flash sold to consumers is always in Bytes (big B); it's only RAM manufacturers (and EEPROMs) that use the bit (small b) designation for storage volume, I think. If you're using both to avoid any confusion, I would suggest the following instead: 128 MByte. No one will ever get that confused with megabits, and it's the same style used for data transfer, which does still use bits: Mbit/sec.
I wish you the best of luck in your search.
The only way I'm able to reconcile the author's title and article to any applicability to software engineers (ostensibly the primary audience in this community) is to assume that the author wants software engineers to be involved further "upstream" of the software product development process.
Code review answers: “Should this be part of my product?” That’s a judgment call, and it’s a fundamentally different question than “does it work.”
No, but yes. Against the assertion from the title, bug-finding is very much a potential answer to "does this bug belong in the codebase?". After all, some bugs aren't bugs; they're features! Snide remarks aside, I'm not sure that a code review is the time to be making broader choices about product architecture or market viability. Those should already have been done-and-settled a good while ago.
Do software engineers make zero judgement calls? Quite the opposite! Engineers are tasked with pulling out the right tool from the toolbox to achieve the given objective. Exactly how and which tools are used is precisely a judgement call: the benefit of experience and wisdom will lean towards certain tools and away from others. But a different group of engineers with different experiences may choose differently. Such judgement calls are made in the here-and-now, and I'm not exactly keen on going back in time to berate engineers for not using tech that didn't yet exist for them.
If the author is asking for engineer involvement earlier, well before a code review, then that's admirable and does in-fact happen. That's what software architects spend their time doing, in constant (and sometimes acrimonious) negotiation with non-engineering staff such as the marketing/sales team.
That said, some architectural problems only become apparent when the rubber meets the road, when the broader team is engaged to implement the design. And if a problem is found during their draft work or during code review, that's precisely the right time to have found that issue, given the process described above where the architects settle on the design in advance.
If that outcome is not desirable, as the author indicates, then it's the process that must change. And I agree in that regard. But does that necessarily change the objective of what "code review" means? I don't think so, because the process change would be adding architectural review ahead of implementation.
If we're splitting hairs about whether a broad "review" procedure does or doesn't include "review of code", then that's a terminological spat. But ultimately, any product can only be as good as its process allows. See aviation for examples of excellent process that makes flying as safe as it is.
Making the process better is obviously a positive, but it's counterbalanced by the cost to do so, the overhead, and whether it's worthwhile for the given product. Again, see aviation for where procedural hurdles do in-fact prevent certain experimental innovations from ever existing, but also some fatal scenarios that fortunately no longer happen.
In closing, I'm not entirely sure what the author wants to change. A rebrand for "code reviews"? Just doing something different so that it feels like we're "meeting the crisis" that is AI? That's not exactly what I would do to address the conondrums presented by the rapid, near-uncontrolled adoption of LLMs.
This is the precise question that Soatok discussed here: https://soatok.blog/2025/07/31/age-verification-doesnt-need-to-be-a-privacy-footgun/
Google recently published an open source library that proves a user’s age in a way that preserves privacy. This library is undergoing two independent security reviews, but should be production-ready in the near future.
If we’re going to force websites to implement some kind of age verification for adult content, we should demand the governments that pass these laws provide the zero-knowledge proof technologies to satisfy the law.
It's hard for me to agree with this premise. Specifically, the motion that companies will abdicate having their own space, in the form of a mobile app and UI. The author seems to suggest that the future will be API-driven, as more people want to "do things" rather than "go somewhere". That is to say, if I may further summarize the author's claims, the future of mobile computing is less about creating a digital storefront to invite potential customers into, but to be as transactional as possible.
And while it is exceedingly enticing for me to think that one day, we could have a way to instantly cancel a Netflix or Comcast subscription, without the need to interact with any service agent, skipping over the upsell or retention attempts, and getting straight to the point, that just seems too far-fetched and anti-capitalist to actually happen in the near future.
Why would it be that at this particular moment in history, when corporations seek to own more capital, would they then seek to abandon their digital storefronts? At the moment, they have sole control over that space, and the present abandonment of anti-trust enforcement means they can force people into their storefronts against their will. In an environment where arbitration agreements are forced upon consumers, why would large companies want mobile apps that don't hold their customers as hostage? Having an open API to do the same thing as their app is tantamount to freeing the consumer.
And that's precisely why I can't see why they would do that. I don't like it, but that's the present reality. But even more to the point, abandoning apps would be bending the knee to AI companies like Google or OpenAI, since it establishes the AI agents as the kingmakers. What sort of a Game of Thrones is this?
For each app that exists now, their corporate owner is a king in their own kingdom. In this supposed new world, those kings are now mere nobles that pay tithe to their new emperor, from the treasuries of their kingdoms. An entertaining fiction, yes. But as a non-fiction? I might pick a different book.
Glad to see this! And thanks for getting back to me.
Btw, is there a presence for the project on Mastodon? I'd like to follow along on new stuff in this space. Or even an RSS feed that can be pulled by a bot on Mastodon?