1,589 karma · joined April 1, 2010
https://web.archive.org/web/20210520103526/https://freenode....
"The rumors of a 'hostile takeover' are simply untrue - I've been the guardian and owner of freenode since 2017, when Christel, the former owner approached me and asked if I was interested in purchasing it, as we had in previous years discussed this."
> I'm not doubting what people say they're seeing. But you should also consider that asserting the software has such a grave fault effectively alleges I either don't use the software or care about it, or I would have noticed.
It sucks to get these kinds of reports when you are a solo dev who uses your own project, and you really do actively use the software and care about it.
But I feel like I've been trained over the years that the devs very often do _not_ seem to use their own software or care about it. So if a major showstopping problem happens on my machine, and it repros on my other machine, and then again on a randomly-selected friend's machine, I tend to assume it's widespread and the devs just don't care that much. (I still try to clearly state the repro conditions as best I am able. But if I can't find a system it _doesn't_ repro on, then it's hard to be specific.)
Sadly, this is probably a case where lots of otherwise-good users have been let down by shitty devs, and lots of otherwise-good devs have been let down by shitty users, and nobody trusts anybody anymore.
(Most recent irritating example: Google Sheets for Android has a 'remove' menu item in the 'Last opened by me' view, which claims (when I select a document owned by another user) that it will remove the document from view, but "Collaborators will still have access." At least the last two times I checked, this isn't true; it will effectively delete the document, for everyone but the owner. This has been the case for months at least; I believe it may have started when Google Drive switched their model to disallow "hard links" of documents. I'm suspicious about whether anybody on the Google Drive team has a very clear mental picture of what their sharing/containment model even _is_ anymore, at least for free users who don't have a "workspace". I reported this using the 'feedback' tool in the app, but I'm well aware that it will not reach anybody who cares.)
Fortunately for Starlink, there's not much worry about Comcast having any of those things.
My take on this: I remain unconvinced that any form of Proof of Stake can give the same security properties we easily get from Proof of Work. I won't say never, but getting Bitcoin to move would take a very convincing argument about the viability of PoS, and so far that's not happening. (Especially given that the poster child for PoS does not actually _use_ PoS yet, they just keep promising it "soon".)
People definitely do not read those. The less useful their PR is, the less likely they are to have read any of the stuff in the template.
(Note: I don't work for Google, and haven't for many years. I mostly noticed this change because it finally fixed a longstanding directions issue that I first reported ABOUT TEN YEARS AGO, involving directions to the Pittsburgh International Airport.)
I want to know how I, a human being running a mailserver, can consistently ensure that other email users -- most notably Gmail users -- can consistently receive and read the _individual_ emails I send, at a rate of _maybe_ half a dozen on a busy day.
As far as I can tell (admittedly largely from the stories of others, as I have basically given up on this myself at this point), there are lots of guides to deliverability of email marketing campaigns, and Google will work with marketers to ensure that their email gets delivered, but for a small non-commercial mailserver without a full-time staff it's not really practical to expect reliable delivery. Which seems sad and backwards to me.
(I couldn't say what fraction of my employment paperwork was handled in this way, but things like IP assignment were definitely included.)
I am increasingly seeing failures where sites seem to be blackholing outgoing email, I suspect based on the destination domain, and unaware that they are even doing this / extremely insistent that they are not. I've gotten login-email failures like you describe from a couple of sites, and seemingly similar failures from those "email your kid this story" sharing systems on two news sites my mother uses. In all these cases, the messages simply never arrive at the destination SMTP server.
* Is the call 1:1 or extremely small? If so, it's down to the preferences of the people in the call. Otherwise, for larger calls:
* Are you in a quiet environment? * That was a trick question. You are not in a quiet environment. You think you are, because your human brain is good at filtering out background noise. Your microphone is not. You are not being forced to actually listen to what your microphone hears. The rest of us are. Mute your fucking microphone!
I can't tell if you forgot about Ava's, or if you've never actually _been_ to downtown Mountain View, or if you only consider chain supermarkets to count.
https://onlinelibrary.wiley.com/doi/full/10.1002/jmri.26637
For their purposes, "low-field" goes down to 0.25T, which is still somewhat higher than the machine linked here, but they extrapolate values of some of the parameters all the way down to 0. (And it seems like the general principles are mostly the same.)
A consequence of this choice is that ANY file concatenated with a ZIP file is a ZIP file (and the same therefore goes for JAR files as well.) So if you concatenate an MSI file with a ZIP/JAR file, your MSI file detector will look at the file and go "yeah, looks good!", and your ZIP/JAR file detector will also say yes. (This also shows off the hazards of automatic filetype sniffing.)
This is related to one of the very oldest Android rooting vulnerabilities. The update.zip files use the signed JAR file format, where the file contains a signature on its own contents. Naturally the signature can't cover the entire file; it only covers the contents referenced by the header.
But the sin-that-keeps-on-giving strikes even harder here: The end-of-file ZIP header also has an end-of-header comment field, of arbitrary size! This means that a single file can actually have MULTIPLE valid ZIP headers. Which means two different tools can interpret the file as two different ZIP files (much as the bug here can interpret the same file as either a ZIP or an MSI.)
Don't do drugs, kids. And don't do automatic filetype detection. And don't do ZIP/JAR files if you can avoid it. And for the love of god, don't put your header at the end.
"May put your account and device at risk" is not going to get you a viable third-party app ecosystem, especially when it's an open question what Facebook/Oculus might decide to clamp down on in the future.
If you are into puzzle-light exploration in a beautiful space, I would highly recommend Fujii as a hidden gem. The only drawback is that it's pretty short.
Not really "content", but if you are interested in productivity apps, Immersed or BigScreen are among the options for streaming your desktop to your headset, depending on what platform you're on. They can also be used for online VR screensharing. (Disclosure: I have a small stake in Immersed.)
The various streaming apps (Netflix, Amazon Prime Video, Youtube, etc.) are not exactly novel, but I like being able to watch stuff without being in front of the computer. (I finally have the screen on the ceiling that I've always wanted.)
Could be a different incident and a different machine, though. I'm sure this story happened more than once.