I can’t speak for who you’re replying to but having to maintain my phone like that sounds awful. I have my computer that I can endlessly tinker with—I want my phone to be a phone and just work.
This is one of the main reasons I used Windows Phone 7 phone for so many years. All of the phone features, enough smart features to make it great for work, and none of the distractions -- ironically, the things that made it a commercial failure.
Bank apps don’t work. Some enterprise security apps don’t work. Rooting is a pain, and custom boot loaders require investment of mental bandwidth that I’d much rather dedicate elsewhere. Which isn’t to say I don’t see the value of it; a couple of years ago, used to play with them. But priorities have changed, and I just want a phone that works.
Switched to iPhone after being on android all this time (with a brief dalliance with Microsoft phone on the lumia 910, which I think is still one of the best smartphone UIs) for the same reason as parent.
I'm an Android user for the ability to do this exact thing, but there's a huge difference in unofficial vs official software support. While you can certainly flash a custom ROM to an Android phone when software update support ends, clearly first party updates would be preferred, at least from a security perspective.
As a Galaxy S8 user, I absolutely would, but I have the International Edition with a Snapdragon processor (G950U), and the only remaining (safe / reliable) root methods only apply to the models with the Exynos chip.
I was an android early adopter, had my share of custom roms and their attendant issues with drivers. Enough to me.
I admire those projects, but no, thanks, I have better things to do with my time.
Translation: “now I can never use cryptocurrency apps because I compromised my own phone and others will take advantage of that when I least expect it”
> It didn't help that I was rewarded with more money, more respect, and more decision making power. I was even rewarded with more knowledge than everyone else -- you learn a lot working 12 hours a day. And if you screw something up you have plenty of time to fix it.
As an intern this feels like everything I want though. More money, more respect, more decision making power, and most importantly, more knowledge. Fortunately my job is done after 4 months no matter what.
> sql.js only allows you to create and read from databases that are fully in memory though - so I implemented a virtual file system that fetches chunks of the database with HTTP Range requests when SQLite tries to read from the filesystem: sql.js-httpvfs. From SQLite’s perspective, it just looks like it’s living on a normal computer with an empty filesystem except for a file called /wdi.sqlite3 that it can read from.
From this paragraph it should be pretty clear that it's actually a great result. The database will obviously need to read more data than it presents, so more is fetched.
How does the code size compare with a traditionnal C approach? The book website mentions using STM32 which usually have plenty of space (64-512kB). How well would it work for say, an ATtiny with 2-8kB of program space?
Wouldn't it still be difficult? The HJKL row makes sense to remap to DHTN. But other commands are mnemonic and would make more sense to follow the key to its new location.
So you have collisions. ("Does Y mean "yank"? Or does it now mean "to"? Well "to" can't be T anymore, because that's now the motion up command.")
So you have to either remap everything back to qwerty positions, and learn the new mnemonics, or keep the letter associations the same, and give up on the clustered motion commands.
I'm thinking it's probably better to do the latter, but I'd love to hear from vimmers that use non-qwerty layouts.
I'm not a power vim user but sticking to the default keybinds on Dvorak isn't so bad. JK are still right next to each other, and HL are on the right index and pinky, respectively, so the basic spatial relationships between the keys are somewhat preserved.
I find that remapping shortcuts is generally not worth it. Yeah, undo/cut/copy/paste are weird and that sucks, but it's better than fighting every application you ever use, on every machine, including machines you SSH into, until you die.
For gaming, on the other hand, mixed up keybinds are intolerable. I just switch back to QWERTY for that.
I type Dvorak and simply use the default Vim key bindings. Vim defaults are weird with Dvorak, but significantly more intuitive than what the situation is with Colemak. Here's the Vim and Dvorak inspired custom keymap I use on my programmable keyboard: https://github.com/1MachineElf/qmk_firmware/tree/_sb4dv/keyb...
I've been on Dvorak full-time since 2008, and even though I generally don't use vim itself for programming, I do still use vim-mode in my editors and IDE. But I gave up on using hjkl long before switching to Dvorak, and I've always just either used motions like w/b/f/t/n/etc, or moved to the arrow keys for shorter motions. This also lets me share more of the muscle memory for movements when I'm typing into standard text boxes like this.
Kind of ironic. I'm on a 75-key keyboard, with no arrow keys. Instead, they're mapped to a layer under (drumroll...) HJKL.
So even if I ever did make the jump to Colemack or Dvorak, I'd probably keep those mappings to the same physical keys. Working in vim, I'd just use my "arrow" keys rather than the native motion keymappings.
I also try to avoid using them in the first place (instead using w/b/f/t/n/etc), but sometimes it's faster to just tap the key a few times rather than "formulate a plan" to reach my target
I've been using vim user for about 10 years and a colemak user for probably 9 years. At first I remapped the hjkl keys to maintain the muscle memory for movement, but ended up going down the rabbit hole of remaps. Eventually I gave up and reverted to the default keybindings. At first it was weird, but after a month or so I got used to it.
I would definitely advise against remapping vim bindings. The first is because if you ever has to use vim on a non-colemak machine, figuring out the keys will be very painful. Secondly because vim has influenced a lot of other programs (man, less, gvim, etc) and most of them are much harder to rebind if they even support it at all.
I have three libraries supporting API 14, one app API 16 and another API 21. There's rarely a reason not to support at least API 21 for general apps. Almost only very specific and niche APIs were added after that. Not supporting at least API 24 is unreasonable and most likely due to ignorance. Java 8 is only supported since API 24, but everybody switched to Kotlin ages ago.
