… and force push.

If you ever find yourself in a situation where rebase or a force push seems to be the solution, take a step back, clone your repo in a new directory and copy the changes into you’re new checkout - ‘cause you gon’ and screwed somethin’ up, son.

trunk?

“… lost in… spaaaaaaaaace.”

Oops, wrong cannon.

… I bet they’d be able to work remotely if they switched to Slack :P

Take a look at ssh-agent. It’s bundled with ssh-client and designed to solve this problem.

The quick usage is, create a terminal and run:

eval `ssh-agent`
ssh-add /path/to/your/encrypted/key1
#type in password
ssh-add /path/to/your/encrypted/key2
... 

# all commands in this terminal will use the keys above w/o asking you for a password 
git clone [email protected]...
git push... 
etc

So, basically you type your credentials once during the life cycle of your terminal.

If you really want to go full power-user, simple run ssh-agent (without the eval) and you’ll see it just sets some env-vars, which can be imported into any terminal/shell you have open.

So, if you put some logic in your shells rc file, you can effectively share a single ash-agent between all your shells, meaning you just need to type your password for your keys once when you log into your system… and your now passwordless for any future terminals you create (this is my setup).

Also, if you’re interested take a peek at the man pages for ash-agent. It has a few interesting features (ie: adding a password lock for your agent, removing keys from the agent, etc).

Without getting too critical of your code (congrats BTW), never use strcpy instead use strlcpy.

strcpy will happily allow you to create buffer overflows (a common challenge with C) which will cause your application to crash.

You’ll find more details here.

Good luck!

The handful of us have moved onto Crystal Lang. It’s a statically type checked and compiled dialect of Ruby. Crystal is fun to write code, but the compiler is slower (compared to go-lang/rust)… because… well it’s a ruby dialect (with DSL’s)… and the 3rd party libraries are limited.

How do you think this technology would be abused?

If the device included full audio and video surveillance - I’d totally agree. However, the device does not include video (and it would be a real hard sell to include that).

If all parties are aware that monitoring will occur (maybe include a sign in the door), I’d argue that minors are aware of what this means.

Perhaps, it would mean that students “finish up” faster, rather than loitering and vaping (or bullying, etc)… and if that’s the case, I guess the device has fulfilled it’s purpose.

The article did mention how a hacked device could be used to “play sounds” or trigger false calls for “help”, or gunshots. But I’d argue this would be the modern day equivalent of falsely pulling the fire alarm.

An interesting article and tbh, I’d actually support the device (… and I’m usually very privacy focused).

According to the article the purpose of the microphone is to listen for certain keywords (ie: “help”, “call 911”, gunshots, etc) and to detect when people are vaping, etc.

I mean, I would never install one in my home, due to privacy and security concerns. But if you’re in a public place, like a school such features make sense.

If you’re being bullied or need help, having a facility member “hanging out” in the schools public bathroom would be weird, creepy, and more of an invasion of privacy than a mic in a smoke detector.

That said, students and facility should be aware of what this device is doing and why. However, this article does a very good job of summarizing that.

Yes, the devices security is rubbish, but was patched. It’s not the first IoT device to do that and it won’t be the last (unfortunately).

Thanks for sharing the article OP.

There was another thread (which I cannot find atm), which said that the author cannot make an Android port, because due to the nature of android (or Google?) the android app would not get the same level of privacy as in the iOS version.

edit: I found the link.