I’ve worked at several different places with widely varying processes.

Current place, we do code changes in Github PRs with CI and deploy to multiple levels of testing environment for our testing department and our customers’ testing departments to try out. At various points, we designate a release version, do testing and documentation on that, and release it. We have a in-house built system for deploying onto all of our environments, so by the time something gets released to production, it’s been deployed using the same systems many times. We have a variety of monitoring systems, which includes a custom application that regularly hits a test route on our services and reports failures, logging services that watch for keywords in our logs, and AWS CloudWatch alarms that send emails.

My personal projects, most of them have few to no users other than myself. I like to deploy with git pushes and run a script on the server to update anything that needs updating and restart the server process.

One of the more interesting ones was at one of my previous jobs. We tried having a testing environment for our application, but we were never able to find bugs effectively in it. The application’s purpose was to do complex calculations on how chemical processes run, and setting up those calculations was very time-consuming for the Chemical Engineers doing it. Nobody had much enthusiasm about setting up tests in non-production environments that were thorough enough to actually expose bugs in the calculations. After several episodes of catching bugs in production instead of testing, we decided to switch to deploying straight to production for one of the smaller projects, and update other, bigger projects to newer versions after they had been used in the first project for a few weeks or so.

You might miss the point of this article if you didn’t read to the end - essentially, all modern web browsers have so much messy C with so many bugs with security implications that they don’t have time to file CVEs for all of them. He argues that, though imperfect, Rust at least has a chance of fully replacing C and dramatically increasing safety in the software we use every day.

The .NET stack never existed as a viable platform for the popular/consumer startups. That said, there have been many “startups” in industries aligned with the enterprise that have been very successful with .NET. You just don’t hear about them because their value proposition was very different, and they weren’t a startup in the same way. Azure and modern .NET are trying to change things, but I think the former makes the biggest difference.

I’ve been happy-enough with LastPass - I can’t point to any reason beyond inertia, so really what I’m curious about in this thread: are there any significant differentiators that could sway a person to switch?

checks Github Nope, no PRs for any of these as far as I can tell.

Although, I suppose our server load is already pretty low anyways. Still, it never hurts to cut response times where we can.

I’m happy with WSL on Windows 10 for all of my unix-y stuff on Windows needs. I’d say I actually prefer that to running a bare-metal linux install on my own hardware. I run the bash terminal through the Cmder command-line interface, and it works fine with Tmux, Vim, and every programming environment I’ve tried so far, including Ruby, Python, Go, Rust, C, and all related utilities, including ssh, git, and command-line tools. The only issues I have are that switching directories seems oddly slow, and Control-Space doesn’t seem to make it into the terminal.

For graphical applications, I stick with ordinary Windows applications. Use ordinary Windows web browsers, picture viewers, music/video players, etc.

One other minor issue - the Linux applications can access the Windows filesystem, but Windows applications can’t access the Linux filesystem. So if you ever want to use any GUI applications on your code, the project has to live in a Windows directory. But then you can’t really use the Linux CLI Git client anymore, because it doesn’t like what the NTFS does with file permissions. So you have to do all of your Git work with a Windows Client. Not to big of a deal IMO, but some may find it annoying.

Because knock packets use a timestamp to limit knock-reuse attacks, servers and clients must have synchronized clocks. Clock skew greater than 60 seconds is likely to cause the knock process to fail, resulting in a “connection refused” error when establishing the TCP connection.

Given this, if my server’s clock does fall out of sync, how do I connect to it to fix it if Oxy is my only access method?

No idea how I’ve never heard of this before. They have a pretty nice method for configuring the options for a CLI app, and nice implementations in a ton of languages. I had been looking for something better for building CLI apps in Python and Rust, and this does the job great.

I don’t really understand this. Sure, it’s cool to optimize something so well, but I don’t see the point of going to so much effort to reduce memory allocations. The time taken to run this, what it seems like you would actually care about, is all over the place and doesn’t get reduced that much. Why do we care about the number of allocations and GC cycles? If you care that much about not “stressing the GC”, whatever that means, then better to switch to a non-GC language than jump through hoops to get a GC language to not do its thing.

I have to agree with this. My personal Mac is a 2013 model Macbook, and between how well it still runs and the high price and design compromises in newer Macbooks, I don’t feel much interest in updating it. I am starting to consider replacing it with a Pixelbook, since the price came down to well below $1,000. I already have a cheaper chromebook, but oh those HiDPI screens are so nice.

Just to make this not all snark at poor security, here’s an idea I came up with in a few minutes for how to make a smart lock that’s actually secure:

Lock will Bluetooth pair with anything that asks, but requires a long random key to open. The key is in a QR code and printed as a number on a couple of sturdy slips of paper that are in the package the lock comes with. You download the app, scan the QR code, and you can open the lock. Anyone else can get the app and pair with the lock, but can’t open it because they have no way to get the code.

I’m not a security expert, and I only spent a few minutes on this, so it may have some holes. But it’s definitely better than what this smart lock is actually doing.

Yes. The only thing we need to unlock the lock is to know the BLE MAC address. The BLE MAC address that is broadcast by the lock.

Wow, that’s awful! I wonder if anyone has some good lock recommendations that have passed testing with good marks?

I don’t really understand the huge variety of languages in these things. Chromium is mostly C/C++, okay. And I suppose they need some JS around for internal UI stuff. I suppose it makes sense to have some Python in there too for build automation or something. But why do they need Python and Ruby and Perl and PHP? And Lisp and Go and Scheme and R and Powershell and Sed and so on? I have to wonder if there are good reasons for all that, or if these projects need some language synchronization.

Wow, what a rant. I’m very sympathetic to “people should be able to control their devices”, but this rant is missing a number of key factors:

• The author’s assertion that this has to be inserted as an NSA backdoor is a link to them ranting about NSA backdoors on IRC. Yes, “just because you’re paranoid doesn’t mean noone is out to get you”. But it also doesn’t prove they necessarily are…
• The author ignores the fact ChromeOS has a security model (and actual, real, historical consumer-level threats to desktop computer users that they are trying to mitigate).
• They also seemingly ignore the fact that a 100% open device belongs to everyone who wants to own it, not just everyone with access to Google’s signing keys. The current device requires you to trust Google, their ideal seems to require you to trust everyone.
• The author ignores the fact that a quick look at the published cr50 firmware source shows that there are a number of things a Rockchip-based laptop needs from some external microcontroller of this kind, aside from TPM-like functionality (power sequencing, battery gas gauge, etc).

In other words, there are clear and obvious reasons (security and basic functionality) why a small management microcontroller like this needs to exist in a laptop (without requiring an NSA conspiracy to insert it.)

At the same time, I totally agree that it would have been great & less problematic if Google had provided a way for advanced users (who understand the associated risks and loss of security) to disable the TPM-like functionality of this chip (ie Android bootloader unlock or older ChromeOS style). Or even better to provision their own signing key. It’s a shame they didn’t do this[*], although not too surprising given the market demand.

[*] It’s worth noting that even if they had done this, the OP wouldn’t be happy because they still can’t audit the rest of the H1 chip’s firmware, build their own, etc. This is a fair enough concern, but it’s hard to see how Google can mitigate that without either finding a TPM-like chip with a fully open source SDK (…), or provisioning two microcontrollers so it’s possible to physically disable the TPM chip entirely but still have a chip to monitor the battery voltage, make the power button work, etc.

This is one of those things that makes me feel sad about the future of the web. It seems like our only choices are between publishers who want to load up the web with autoplaying videos, ADD-inspiring redirects to more articles, and endless piles of ads and tracking scripts, and tech behemoths that want to put the whole web under their proprietary protocols and in-house services. There doesn’t seem to be any forces pushing for quality content on readable pages with reasonable, trustworthy ads or some other sort of monetization.

I really hate browser notifications. I never click yes ever. It feels like preventing browsers from going down this hole is just yet another hack. The Spammers and the CAPTCHAers are fighting a continuous war, all because of the 2% of people who actually click on SPAM.

Have you tried BGAN? Satellite internet from a panel the size of a laptop. I field tested some of them for a project a few years ago, they worked pretty well and were easy to set up.

We didn’t end up going with them for that project, IIRC because it was for deployment in less remote locations in the US, and they didn’t support the US at the time, and we had good alternatives - cellular data in most places, and we had the transport capability to bring full-size satellite dishes.

Distaste of Electron in general aside, I think the author does have a point in that you would think we can come up with a way for Electron apps to run more directly in ChromeOS. Do we really need to run basically Chrome on top of a stripped-down Linux, then run another full Linux container inside of that, and run another instance of Chrome inside of that?

Although looking at his apps list, Slack is already an Android app and web app, can run fine on ChromeOS in multiple ways. Hyper appears to be some sort of Electron-based terminal. I have no idea right now why you would want to do that, but there are several types of terminals on ChromeOS already. Don’t know much about SimpleNote either, but it also looks like it’s already a web app and an Android app. VS Code is the only thing on the list that doesn’t really run in some form on ChromeOS already.

Funny, I just read this article on how most PGP mail clients have some serious security flaws right after I read this post. I was already inclined to think that really secure email for like 99% of possible uses is hopeless. The most important issue IMO is that whoever you are communicating with is likely to be less paranoid/concerned about this than you are.

The other thing - the NSA and any other potential adversary combined just don’t have the analysis bandwidth or storage to do anything useful with the amount of data they would get from compromising everyone in this way. If they have such valuable vulnerabilities, they aren’t going to spread them all around the world and risk them getting discovered and patched at any time in exchange for data volume that they can’t store or analyze. They save them for very limited application against high-value targets.

I’m not saying they don’t gather massive reams of data where they can do so easily. I do think they don’t want to put their most valuable vulnerabilities at risk of discovery without getting something they really want out of it. Look at how many vulnerabilities made it out into the wider internet and were discovered and patched when that Flame malware spread farther than its controllers intended on the open internet.

Huh, what would a federated message board look like? I guess I could see a reddit-like one where each sub could be on a different server, but you’d have a shared account around them all. Still one server per forum, so you can have consistent ordering of stories and comments. I’m not really sure what the benefit is to anyone of having a shared account among a ton of federated board servers, though. It just preserves reddit weirdness like sharing massively different karma amounts between joke boards and deep research boards.

Lobsters is meant to have one main page though. How would you do consistent ordering of the front page if stories were federated?