EvanDotPro

Love the creativity! Not only storing the data directly in the file, but also the clever hackery to make a single file that renders a page in the browser yet can also be executed in the terminal with Node. Very cool!

I've long felt that what the IA does is extremely important and as most people here are surely aware, they archive a heck of a lot more than just webpages.

I currently have them set as my Amazon Smile charity — perhaps something to consider for anyone not feeling up to a one off donation.

I use Bluetooth ear buds (OnePlus Buds) daily on Fedora with Pipewire and haven't noticed any perceivable sync issues myself.

Edit: Other comments are mentioning codec selection for Bluetooth in relation to lag/sync issues. I'm using whatever is default on Fedora 34. I've never looked and am not at my computer to check right now unfortunately.

Long time daily Fedora user here. PipeWire is what we've needed for so long in terms of audio, not to mention more recently in terms of screen capture with Wayland.

The only issue I've run into is that for some apps (Zoom, Firefox, Chrome) which are set to use my "default audio device" for input or output, it selects the correct device initially, but if I change the default/system device (via gnome sound settings) later while it's in use, most (all?) of the time, the application continues using whatever device was selected initially.

I haven't bothered to debug or see if this is a known issue as it hasn't bothered me much since most apps allow switching to explicit input/output devices which works fine. I believe (but haven't definitively confirmed) that changes via pavucontrol also work, so perhaps it's something with the gnome sound settings?

Anyway, huge thanks to the devs who put their time, effort, experience, and talent into making PipeWire happen. It's a huge step forward on multiple fronts

Only one of these two statements is true.

I haven't looked in a while, but last time I checked, Magisk had a SafetyNet bypass. It's a cat and mouse game of course, but when I was using it, Magisk stayed ahead of Google 90%+ of the time.

Sure, I'm not a total purist about it. What's important to me is maintaining the logical progression of a change, even if it includes some dead ends, non starters, or mistakes.

If you want to amend commits for a typo, code style fix, or otherwise inconsequential change that doesn't add any useful context for future developers, by all means go for it.

I've always advocated maintaining true, "messy" history (in git) amongst my teams. I know it's controversial, but anecdotally, verbose history has helped me understand the nuance of otherwise opaque changes and decisions so many times that I can't help but cringe when a bunch of context is lost to squashing for the sake of a "clean" history. Many of the technical arguments for squashing tend to be things that can be mitigated by simply traversing merge commits only.

As a LONG time Vim (now Neovim) user, I've been pretty curious to try this as it would allow me to retain some of my beloved plugins and custom config without the effort of trying to find replacements or reproduce my config stuff. I imagine I could also get rid of most of the language server / autocomplete / code navigation type stuff that comes easier in VS code. It could potentially be the best of both worlds if it's done as well as I'm hoping it is.

I haven't tried it yet, but my main concern is that VS Code probably has a lot of keyboard shortcuts (e.g., C-v for visual block mode) that I'd have to reassign, which could potentially be a bit of a pain initially.

Mind sharing any pros/cons you've run into with the Neovim plugin so far?

After reading the article and the comments here so far, I'm legitimately struggling to decide how I should feel about this as a long-time WMF donor. I can understand the upset and deceit people are feeling, but I am also aware of the many initiatives WMF is behind, their endowment fund usage is strictly controlled from what I understand, and as a business owner, I also deeply sympathize with the idea of having "rainy day" money but continuing to behave as if you don't.

Is there some middle ground here?

In my experience with Cox, you simply plug it in and it just works. It might take a little longer to initialize with a new MAC, but I've never had to call or notify them of a modem swap.

Found another Android widget alternative: https://play.google.com/store/apps/details?id=com.davee44.da...

Just found this little gem for Android that allows you to have progress bars like these as a launcher widget.

https://play.google.com/store/apps/details?id=com.donationco...

I had actually forgotten all about the discussion filter and hadn't noticed it was even removed until reading this comment. I never utilized it much back when it was available but in retrospect can definitely think of cases where this would've come in handy if I had thought to use it.

I immediately thought there must be some clever combination of query modifiers that could roughly reproduce the discussion filter behavior... Of course I'm not the first one with this idea— there seems to be browser extensions[1][2] that accomplish this by appending your search query with:

  intext:forum "post"|inurl:forum|"posts:"|inurl:viewtopic 

It seems to work reasonably well after a couple tests and could probably be improved to catch more discussion sites with some additional piped modifiers if necessary. Anyway, just thought I'd share my findings.

[1]: https://chrome.google.com/webstore/detail/discussions-button...

[2]: https://addons.mozilla.org/en-US/firefox/addon/google-forum-...

I haven't researched the JS options in this space yet either, but if anyone reading is looking for something like this for PHP, there is Roave Security Advisories — https://github.com/Roave/SecurityAdvisories

Add it to your composer.json and it will simply conflict with all lib versions with known vulnerabilities.

The data source used (https://github.com/FriendsOfPHP/security-advisories) has an excellent history of keeping up-to-date.

Disclosure: I'm the founder of Roave.

I'm in a very similar situation, and overall have found GV to be a net positive despite the imperfections.

The only additional caveat I've found is that the proper carrier-level call forwarding to GV voicemail doesn't work with the $30 T-Mobile plan.

Technically yes, but I would imagine they'd subsequently hash the hash on the server side as well.

I assume the extra client-side hashing is done to keep the plaintext passwords out of the application memory, not protect it in transit.

To clarify, this is just an assumption. I have not read up on the topic nor do I claim to be a security expert. This is just what came to mind when I had the same thought as you.

Anyone else know for sure?

Ah, glad someone else with experience is in this thread. You've saved me a bunch of typing.

This is not true at all. I can give you the current provider of a number that had been ported and my data will reflect a new port within minutes of it taking effect. Oh, and it's an order of magnitude cheaper than what Twilio is charging for this... I couldn't tell you why Twilio's implementation is out of date and so expensive.

This is likely done with something called an HLR lookup via SS7. I believe it was explained to me that HLR lookups are meant for call setup and SMS routing, NOT for exposing network information via web services, but that doesn't stop companies with SS7 access from doing it anyway since there are plenty of people willing to pay for that information.

Wow, $0.005 is incredibly expensive for carrier lookups. I run an SMS gateway and our cost for this is $0.0001 per lookup from our primary provider and $0.0002 from our backup provider. Of course we are dealing in bulk but Twilio should be too...

I'm sorry, I actually mixed up two different experiments regarding the performance issues (I've been playing with this stuff for a looongg time and have many different prototypes). Allow my to clarify. :)

The performance issues with using Broadway.js were more "general", in that the experience varied wildly, from amazing to unusable depending on the browser/device/etc)... Not necessarily related to Websockets + Webworkers.

The Websocket issue on the other hand, was for a more recent experiment where I was playing with the idea of bridging NoVNC over WebRTC data channels.

It's not so much a performance "issue" as much as a "possible area for optimization"... Though, every time I'm playing with noVNC or Broadway.js in a FF tab on my i7 laptop, it pretty much renders FF pretty laggy in all other tabs. I imagine offloading as much of the processing to workers as possible would be the best approach to lessen the effect — though, I'm not much of a frontend / JS dev.

Here's the noVNC issue: https://github.com/kanaka/noVNC/issues/114 And the bugzilla for FF: https://bugzilla.mozilla.org/show_bug.cgi?id=504553

I've done A LOT of research and experimentation in this space over the course of the last 5-ish years, mainly out of sheer curiosity. This sounds very, very similar to something I prototyped a while back using x264 + Broadway.js (HTML5 video streaming with low latency is a non-starter).

I'm extremely curious, has Paperspace actually developed an entirely new video codec, encoder, and efficient JS decoder for this?

I'm a little confused by the statements so far (and the comments are flowing in, so apologies if this was addressed while I was typing): "we are using a video stream", "using a JS renderer", "building a streaming protocol", "using GPU tech originally developed for video game streaming", "a remote desktop protocol that could stream HD video"

So, is just the streaming protocol you've developed and not the codec? In my expiriments, simply pushing out h264 NAL units over websockets and passing them to the decoder was a pretty solid start. Add a tiny layer of buffering over that and I imagine it'd be fairly stable. Ultimately, I backed away from h264 for licensing and performance issues.

Also, what's the transport into the browser? Websockets? WebRTC data channels? Have you encountered performance issues with Firefox not being able to handle websockets or data channels in web workers? (Which is seemingly coming in FF37.)

> We can assure customers that any bitcoins held with us prior to temporary suspension of services on January 5th at 9am UTC are completely safe and will be fully honored.

I, for one, am glad to see a Bitcoin story turn out with a somewhat positive outcome, at least from the users' perspective.

That said, the article says a breach resulted in the loss of ~19,000 BTC, or around $5.6 million. If they're honoring all user funds, does that mean they are just eating that loss out of their own profits, and perhaps try to file an insurance claim? Or were they actually responsible enough to set enough profits aside in cold storage self-insure the total amount floating in the "hot" wallets? On that note, I wonder if profits and hot wallet demands scale proportionately or not, or if their margins are just at a scale where this is a non-issue?

The only correct answer to this is to spend some time to go (all the way) through the getting started guides for both.

Now, if you are sincerely planning to shape your career on this decision (and because you didn't clarify how you narrowed your decision down to Django and Rails), I'd recommend taking advantage of your current flexibility to get your hands dirty with a wider array of the options out there before investing copious amounts of time specializing on a single language/framework.

In your position, I'd take this time to actually go through the getting started guides for at least a couple of additional languages/frameworks (e.g., Symfony, Zend Framework, etc for PHP and Meteor, Express, etc for Node.js). This will allow you to find the stack that's a genuinely good fit based on your current skill level, opinions, experience, etc. This should not only give you confidence in your decision, but more importantly, it's sure to make the entire learning process much more enjoyable. Additionally, this approach would give you exposure to the documentation quality of the various projects in the process.

All tech arguments and language hate aside, specializing in any of the languages/frameworks mentioned will absolutely make you employable by a wide variety of companies in the current market, so personally I wouldn't stress over that aspect of it very much. That is, unless you're only planning to entertain local opportunities and live in a region which lacks tech diversity. In that case, your local job market should probably be a more important factor in your decision.

I find the bold search terms useful and interesting to identify when Google has performed any sort or fuzzy match (synonym, acronym, etc). For some obscure searches, knowing that a fuzzy match is affecting the results might cue me to refine the search with quotes to bring more relevant or precise results to the top.

Maybe I just need to get better at Googling.

I just applied for an invite and received it in ~15 minutes.

I suppose it's only a matter of time before one of these persistent web clients / services converts me, but my current setup works surprisingly well:

- Irssi + screen on my server.

- IrssiNotifier [1] for push notifications to my Android phone when I'm hilighted/PM'd.

- Connect from my phone using Irssi ConnectBot [2], which is just an SSH client that supports gestures for interacting with Irssi (swipe left/right to switch channels, double tap to go to a hilight, swipe up/down to scroll the channel log, etc).

- Connection via mosh [3] instead of plain SSH. Mosh uses UDP, which allows persistent connections when switching from Wi-Fi to cellular data, or when data connections are spotty, etc. On my phone, I actually use a patched version of Irssi ConnectBot [4] which supports mosh.

That said, as well as this works, I've always kept an envious eye on browser-based implementations like this. I love thinking about all the fun integrations that would be possible to make IRC a much more rich experience: automatically showing YouTube thumbnails/descriptions, expanding shortened links, hover-to-show image links, etc.

[1]: https://play.google.com/store/apps/details?id=fi.iki.murgo.i... [2]: https://play.google.com/store/apps/details?id=org.woltage.ir... [3]: http://mosh.mit.edu/ [4]: http://dan.drown.org/android/mosh/

I wouldn't mind having something like this for long flights without wifi.

Edit: Kiwix looks nice too, thanks!