> The main positive that I see is that typing no longer requires thought.
This is why I've been using keyboards with nothing written on the keys since 2004.
At the time, I was in high school and had no money to buy a professional keyboard, so I spray painted my cheap keyboard with black paint (fun fact: I'm still using that very keyboard to type this).
I've never looked at my keyboards ever since. I can type all letters and all symbols without thinking about it. As an IT person, I couldn't imagine how much brain energy I would waste if I were to look down and search for anything.
I've accepted this a decade ago.
I put my ego on the side, and now I don't care if my git history doesn't look like "beautiful" when looking at the commit graph.
I've been working on dozens of projects since, and probably did thousands of commits. Some of the teams of those projects included dozens of developers working concurrently on the same codebases. We always merged the upstream branches into our development branches and never did any rebases.
I have NEVER ended up in a situation where I thought rebases would have been better.
The git tools and IDE integrations of our current age allow me to find any information I need from the history without pain.
Have you ever had to use git bisect? That's really where a 'clean' git history is important. Plenty of people never use git bisect, and that's fine too. That said it's a very useful tool when you do need it, and can drastically simplify finding when and where a regression was introduced.
You can `git bisect --first-parent` and only bisect top-level merge commits. In most cases that gets you to the ballpark of "PR that introduced the bug" no matter how dirty the commit history inside that PR had been and if you can git bisect further in that branch. In my experience that is most of what you want anyway, "PR that introduced the bug" gives more than enough context.
You can bisect across the more coarse merge commits, without “destroying” history and losing the ability to bisect across more granular constituent commits. Bisect is more robust when more information is preserved.
This exactly. I'd rather pinpoint the issue to a small commit with only a few changes vs. "well I know which feature caused the issue, now to wade through 65 changed files."
Tell that to my previous employer. There, software engineers turned "senior" after 2 years. Then principal after 3 more. It was a scheduled activity to "upgrade". Only X people could turn senior every year because the title changed triggered a salary raise and they could only afford that for X people. I left when I got approval to hire 3 senior software engineers to my team but the salary level was only attractive to the people with zero experience, if that.
I keep seeing this (anecdotally) out if the Midwest. Folks with 4 years experience doing mostly front end work who’ve never deployed anything with the title “staff engineer”.
I sort of feel bad for them because without a large step down in title they’d never get another job. Perhaps that’s the trick - title inflation to mask bad pay?
That's exactly what it is. Many organizations have strict pay bands and cannot attract talent without overly inflated titles; cue dozens of "directors" with no reports, and people with < 5 years experience being hired as "Staff Engineers" to build web apps.
Do you mean this: let's say they want to hire a senior software engineer, but the salary for this level would not attract any candidates so instead they try to hire a staff engineer?
Mostly trying to understand if this is middle-managers tricking their higher ups or if it's the company trying to trick the candidates.
It's the former. Larger companies tend to have strict pay bands relative to the seniority and responsibility of a position. Let's say intern>junior>senior>manager>director>vp.
If the salary range for "senior" is 50-70k, this might be attractive for a customer service rep but not for a senior software developer. Thus, you'll need to inflate the title to be either a manager, director, or staff/prinicple (if HR recognizes that) to be authorized to offer market compensation for a senior software developer.
I think this is common in companies with a lower salary range, no stock options, bonuses etc.
This is particularly apparent in large cities, where salaries can be almost double at each end of the spectrum. From what I have seen promotion to senior or hiring inexperienced staff at senior level is the only way these companies can retain or recruit staff.
I have a private PKI I use to connect to my self-hosted software: email server, calendar provider, notes server, photo sync tool, etc.
I NEED to be able to add my root cert to the list of certified authorities.
I don't need to change anything to the system provided list. I just need to add mine.
It's my device, I'd like to be able to change anything if I want to.
You can install your own CA certificate in the user certificate store, and it will be trusted by Chrome and any other app which opts into user-installed CAs, which should include email and calendar apps.
What is unlikely to work is installing your own CA and using it to intercept traffic between apps and the app-makers' servers. That sucks - you should be able to inspect what your own device is doing - but your use case of using a private PKI for your self-hosted software is definitely supported.
It doesn't matter how often it happens. It's a vulnerability that people will end up being exploited or the data will end up being stolen by another hacker.
Not all banks allow desktop usage. Some banks restrict certain functionality from the web interface since it is less secure.
It absolutely matters how often it happens. Otherwise we should start imprisoning everyone in the hopes of getting that one serial killer by the same principle. Some cures are worse than the disease.
User certificates still work fine. Apps have to opt into the user CA store (many of them don't) but any app deployed by IT should be fine. Chrome works, Firefox can be made to work, and I believe the Gmail app also works with user CA certificates.
Thanks for the clarification, I was pretty confused by the article on this detail myself. Per app opt seems like a reasonable compromise for my use as long as the browser recognizes my CA, as that's the one I care about.
One alternative is to use public CAs on your private networks. I've been working on tooling for this at getlocalcert [1]. Side stepping the need to add a trust root makes the public on private approach a net win for some networks. I honestly wasn't expecting Android to block private CAs, but I guess here we are.
I was also confused about that. I don't use an Android phone currently, but I remember you could add your own CA certificates to an Android phone -without being root, just using some option under settings- and at least applications like the web browser would trust them. And I'm not talking about long ago. So I couldn't understand if the need of rooting your device to install custom certificates was for something different.
On Android 7, Google changed the defaults for certificates. Previously, apps trusted system certificates and user certificates unless they opted out. On Android 7, apps have to opt into trusting then user certificate store.
Browsers opt in, or in the case of Firefox, can be configured through hidden settings to opt in. Many other apps don't, though.
If you're trying to intercept traffic or use apps that should opt in but don't, the system store could be altered with root access so that these apps still trusted the certificates you're trying to inject. However, most apps worth their salt implement certificate pinning, so that's hardly reliable anymore. It's Arnold workaround that works on some apps but not on most.
Furthermore, Google Chrome and derivatives require certificates to be logged publicly so malicious CAs can't mess with random domains. Your private CA isn't logged in the public record, so adding the certificate to the system store actually breaks HTTPS for many browsers. You can add the cert to both stores to make it work, but it's kind of a hack.
On iOS loading certificates is easier, but you'll still need to work around certificate pinning if you want to intercept HTTPS traffic.
Thanks for your explanation! What I remember is from an Android version more recent than 7, probably 10, but maybe the browser was Firefox so in that case there was no need to have your device rooted.
I'm using zrepl to sync ZFS filesystems incrementally between servers.
I like the ability to incrementally send only the changes of an encrypted filesystem to a target server that never had the encryption key at anytime.
I'm using this to share backup space with my friends. We both push/pull our encrypted snapshot diffs every hour. I don't have my friends' keys so I can't read their data, and they can't read mine. In case of emergency, I can go to their place with my key, and recover my data from their systems.
Have you used sanoid/syncoid? I started my ZFS journey with a custom script and then switched to syncoid/sanoid (and some much simplified scripts) for my backup needs. One of my use cases is for Raspberry Pis which seem to have a habit of becoming unbootable. These are Pi 4Bs running from SATA/USB SSD or CM4s using NVME SSDs. I have scripts that use
* dd to copy the boot sector (to a ZFS filesystem)
* rsync to copy the boot (FAT32) and root (EXT4) partitions (also to a ZFS filesystem)
* syncoid to copy the ZFS filesystem to another host.
This process runs daily. When a system craps, it's pretty straightforward to restore the boot sector and boot and root partitions and finally the ZFS pool.
I'm curious zrepl does that might be useful for me.
I don't need to backup my boot sectors or root partitions since all my systems are provisioned. I can always re-create them with scripts, should any of them fail.
I'm only replicating the data filesystems.
From what I see, sanoid looks quite similar to zrepl. Both tools are probably able to achieve similar results.
I do feel that zrepl has more features so far, though. But hey, if your setup is working and your data is secure, that's the most important.
I 100% agree that the move to etcupdate should have been documented better. I also ended up in situations when I had to manually fix systems after upgrading.
My dorm in 2006 didn't have any wired network (nor wifi).
So what we did is we wired one ourselves through the walls of every room, running ethernet cables from one balcony to the other. Every 6 room, we'd install a cheap fast-ethernet switch.
Eventually, we managed to connect almost all 300 rooms together in a giant single VLAN.
That dorm ended up being a giant eternal LAN party. People would play games all the time, either from their own individual rooms, either after moving their PC using stolen supermarket shopping carts to other rooms for more conviviality.
You'd turn on your PC, and some custom scripts would tell you which games were currently being played, and the only thing left for you was to join the game of your friends, or the game of the total strangers from two floors down.
[Mostly NSFW]
If you want to explore knowledge about the human body and what people do with it, I suggest «The tree of reddit sex life» as an exploration start point:
Sublime Text has been my choice for years. Most often I'm in an IDE or in VSCode, but when I need to inspect or edit a file quickly or find-and-replace across an entire directory I use Sublime. It's nice and snappy.
This is why I've been using keyboards with nothing written on the keys since 2004. At the time, I was in high school and had no money to buy a professional keyboard, so I spray painted my cheap keyboard with black paint (fun fact: I'm still using that very keyboard to type this).
I've never looked at my keyboards ever since. I can type all letters and all symbols without thinking about it. As an IT person, I couldn't imagine how much brain energy I would waste if I were to look down and search for anything.