vvv

joined 1 year ago
[–] vvv@programming.dev 3 points 7 months ago

That's interesting, okay. Is svn doing compression of those binaries for you?

Not to say "you're holding it wrong", but I'm curious about your workflow here. You clone these binaries every time you come back to a project?

[–] vvv@programming.dev 9 points 7 months ago (2 children)

I don't get it, who in their right mind hosts development stuff on a Windows clunker?

Same question, but Subversion. Switch to git. Import your repos with git-svn.

[–] vvv@programming.dev 83 points 7 months ago (2 children)

just to add a little more explanation to what the other posters are suggesting.... a hard drive, from the perspective of your OS is very very simple. it's a series of bytes. for the sake of this example, let's say there are 1000 of them. they are just a series of numbers.

how do you tell apart which numbers belong to which partitions? well there's a convention: you decide that the first 10 of those numbers can be a label to indicate where partions start. e.g. your efi starts at #11 and ends at #61. root at starts at #61 and ends at #800. the label doesn't say anything about the bytes after that.

how do you know which bytes in the partions make up files? similar sort of game with a file system within the bounds of that partion - you use some of the data as a label to find the file data. maybe bytes 71-78 indicate that you can find ~/.bash_histor at bytes 732-790.

what happened when you shrunk that root partions, is you changed that label at the beginning. your root partion, it says, now starts at byte #61 and goes to #300. any bytes after that, are fair game for a new partion and filesystem to overwrite.

the point of all this, is that so far all you've done is changed some labels. the bytes that make up your files are still on the disk, but perhaps not findable. however - because every process that writes to the disk will trust those labels, any operation you do to the disk, including mounting it has a chance to overwrite the data that makes up your files.

this means:

  • most of your files are probably recoverable
  • do not boot the operating system on that drive, or any other that will attempt to mount it, because you risk overwring data
  • before you start using any data recovery tools, make a copy of the raw bytes of the disk to a different disk, so that if the tools mess up you have an option to try again

ONLY after that is done, the first thing I'd try is setting that partion label back to what it used to say, 100gb.. if you're lucky, everything will just work. if you aren't, tools like 'photorec' can crawl the raw bytes of the disk and try and output whatever files they find.

good luck!

[–] vvv@programming.dev 1 points 7 months ago

Hey, thanks for that, I appreciate you sharing your list.

One option you can consider with fairmail and gmail is to use an "app password" to authenticate to IMAP, instead of oauth. That might work better when backing up with neo backup?

[–] vvv@programming.dev 11 points 7 months ago (3 children)

Everything else wrong with Gmail and Google aside, those are the least reasonable complaints? You can use labels as folders. You can also disable conversation grouping, but I doubt you go more than a week before turning it back on.

[–] vvv@programming.dev 1 points 7 months ago

That's an interesting suggestion, thanks! I might wind up trying that for android auto + google voice 🤔

[–] vvv@programming.dev 1 points 7 months ago (1 children)

Hmm, thanks for the suggestion... this looks like it might be mainly for only pixel devices? Or devices that have a LineageOS build? I might be frustrated enough with the problem to learn Nix, but I don't want to be limited to particular hardware.

[–] vvv@programming.dev 9 points 8 months ago (1 children)

Likely relevant John Oliver about these types of scams: https://youtu.be/pLPpl2ISKTg?si=WYsqiiQ4f3U6ZoIe

[–] vvv@programming.dev 27 points 8 months ago

Another way of writing '10'

[–] vvv@programming.dev 2 points 8 months ago

I don't have a particular guide at the tip of my fingers, but I can share some recommendations based on my experience:

  • prefer a phone with USB-c if you plan on connecting USB things to it. the otg adapters for micro-b are kinda hit and miss when it comes to keeping the phone connected to power as well.
  • look out for clearances of those carrier locked prepaid phones from physical stores, you can get nice devices for nearly nothing
  • whatever you're running on the phone, make sure it starts at startup, so you don't need to go launching everything if you reboot for some reason
  • if the phone is"mission critical" e.g. random restart while in the middle of a print is unacceptable, turn off all the automatic updates and such.
  • a VNC server has been helpful, to remotely poke at the phone if I'm too lazy to go do it physically
  • get something that'll keep the screen off the phone on. I've encountered reduced performance regardless of what battery optimizations I've turned off without doing that but YMMV depending on ROM.

I fully expect the screen thing and the batteries bring in there constantly charging to kill the phones I'm using eventually, but it's something I expect and accept. my octoprint phones have been fine so far, for a bit over a year 🤷‍♂️

[–] vvv@programming.dev 6 points 8 months ago (2 children)

there's the open book if you want a Project

[–] vvv@programming.dev 19 points 8 months ago (8 children)

The value proposition of old or used android phones as SBCs is insane! You've probably got some in your drawers, or can at worst buy some carrier locked ones for 30$. You get a device with better compute than a raspberry pi, with a screen, cameras, speakers, flashlight and battery attached!

Personally, I use them to run and monitor my 3d printers.

view more: ‹ prev next ›