null_content

> Even back in the 90's Mysql was able to hide the CLI supplied password from the process list. It would be cool if oathtool was able to do the same.

This has always been a brittle and not easily portable approach.

And doesn't protect you from an attacker doing something much simpler: reading your .bash_history file.

Passing passwords as arguments has always been a bad idea.

Funny that you bring that up because in 1998, Tcl/Tk already had grid layouts (if I am not mistaken).

So yes, you are finally doing UI development like it is 1998.

Congratulations.

Sarcasm aside, want to know what a proper GUI toolkit looks like? Take some time to play around with Qt.

Web development is such a pain because the standard is sub-par (decided by committee, so no surprises there) and the implementation is even worse (full of inter-vendor inconsistencies and missing features).

Frankly, last time I did web development, I felt tempted to just make the entire page one screen sized canvas and implement my own UI toolkit on it. That's bound to be more reliable (and probably faster) that the current state of affairs.

They are deep in Uranus.

As a general statement, that is impossible in both practice and theory due to the halting problem.

You CAN write proven bug free code, but only if you are willing to accept a long series of limitations.

We don't tolerate houses collapsing out of nowhere, brakes failing over the course of normal usage and planes falling out of the sky during routine flights.

But for some reason, we HAVE TO tolerate software crapping itself once a year?

I don't accept this logic. This is just a sign of how sloppy the industry has become.

This is the reason your phone becomes obsolete after 2 years, whereas your car can continue to run after multiple decades of abuse.

That, and Debian would fuck up the implementation.

Lest anyone forgets:

https://www.schneier.com/blog/archives/2008/05/random_number...

Pretty much any device these days can run some form of standalone SSH software or, worst case scenario, a shell + openssh (heck, even Windows can do that these days).

Setting these up is fairly painless, and they are FAR more flexible than this solution, FAR more secure and the vast majority are open source - which is KINDA important when dealing with security.

Sorry for being blunt, but all I see here is a huge gaping security hole. The $5/month is just adding insult to injury.

> Sure, but e.g. on Debian /etc/systemd/system/sshd.service is 22 lines. The still-carried shellscript version is 162 lines, and that's before counting any of the per-distro shellscript libraries systemd removed the need for. That's a big reduction in complexity even if systemd didn't have any advantages over shellscript init, which it does.

And for that "simplicity" all you need is a daemon that depends on dbus, glibc and cgroups (IIRC), just to name a few - which makes it non-portable for anything that isn't Linux and non-usable for anything that doesn't want to depend on, say, glibc.

And if they got their way, dbus would have been shoved into the kernel (kdbus, bus1, or whatever they called it) - adding a bloated mess of an IPC mechanism into the kernel.

Simplicity. Right.

Funny that you bring that up:

https://en.wikipedia.org/wiki/Go_(programming_language)#Nami...