(assuming the bug here is a description being assigned to a title)
getDescription simply needs to return a Description object while getTitle returns a Title object. Duh.
Only in the final rendering should it get turned into a string and there it should only accept a Title type for doing so.
Okay, I'm kind of joking, but this is seriously the solution if you really want to get down to it - primitive overuse is the problem, so wrap it in a type that makes it explicit. You need cheap and easy types to take full advantage of this sort of thing.
EDIT: And even with those reading code developed in such a way may go overboard at some point. I'm not sure as I haven't really seen it done to the fullest extent possible. Typically even when taking a fairly strong advantage of such a type system, unit tests and stuff are still used, but theoretically you could enforce their parameters entirely in the type system. Of course, that enforcement can also be incorrect, but it does make it clearer in many cases.
Yeah, they talked about numbers of bugs fixed, but those surely seem to have impacted the user experience. My big worry is that if I were to consider deploying to such a service, that I would encounter similar bugs, but not have the political pull to get them fixed and simply have to perform hacky fixes around them myself.
If those major distros weren't switching though, you wouldn't have to, which is what my point was. The only reason you're adopting it is not for a practical benefit, just because the distros did.
I run devops though for a small business and we've avoided the issue entirely using runit for our software.
I've switched everything I write to use runit because runit doesn't require any particular init system, you can easily integrate it with sysvinit, freebsd's RC, ubuntu's upstart, systemd, etc. It just runs on top and doesn't need to be the king and it's incredibly simple to write scripts for it. Completely removes the need to worry about this init mess.
The thing is though - their code is already written. Systemd is entirely unnecessary for 99% of people, probably everything except some of it's LXC features has clear and popular alternatives. LXC is the only thing making me eye systemd with interest, but I'll come back to it in a few years once all the weird stuff is worked out.
I looked at it but both price and lack of root and bootloader unlocking are extremely prohibitive for me. The keyboard is really its only appealing feature.
I can get a device like a OnePlus 3 for about 60% of the price and it has better hardware to boot. In terms of storage, RAM and CPU it's more comparable to a OnePlus 2 which is about 40% of its price.
Keyboard is nice, but not double the price and lose features I rely upon like AdAway and XPrivacy kind of nice.
Are there any pickins for android phones with keyboards with even remotely modern hardware (I'd settle for anything with a 1080p screen probably)? Seems extremely limited, I was unable to find any viable options last I checked. I hate the candy bar form factor but it seems as though it really has won out unfortunately.
Yeah, the XBMC Youtube addon used to do subscriptions and the like, it was pretty nice, but I think it broke and the main developer abandoned it. Youtube-dl does support channels and resuming though so you could fairly easily just set up a cron job and use syncthing to get the videos onto your phone. No pretty GUI for that though.
I'd love this kind of report with various things. I'm thinking phones would be extremely helpful too, how easy is it to unlock the bootloader on this phone? How hard is it to repair it? What proprietary blobs does it rely upon?
Cheat Engine is an extremely capable tool too, has lots of reverse engineering features, including a debugger and pointer searching tools, a blue-pill style hypervizor to modify memory undetectably and a very powerful assembly level patcher. Oh, and it's all open source. Seriously nice stuff.
> That is a concern for the DH key establishment though, that might be decrypted in future.
If you're paranoid, configure your SSH server to only accept Curve25519-based key exchanges, only use AES with authenticated modes or CTR+ETM or chacha/poly1305, and only take ed25519 or long RSA authentication keys.
Assuming your clients are up to date it should work without any major impact. I also strongly recommend rejecting NIST "random" curves in your hostkey verification, better RSA or ed25519 than the current default of the somewhat questionable ECDSA-based keys.
Not sure, but my guess would be that the yellow was a hardcoded constant in the code in a few places and modifying it involved opening up system files in a hex editor and doing some edits, amateurs + hex editors = bad times.
I've been thinking about how something like this could be done in a completely distributed way, I think I've even seen some research implementation of it. In any case, it'd be interesting...
Hmm... http://twister.net.co/ maybe? The biggest issue is going to be mobile, but if you have enough people firing it up on servers and stuff, you'd probably be okay. And then of course you realize that there's also the even bigger issue of actually getting people to use it. You're fucked there unless you have some serious marketing talent, which most people capable of writing such a thing in the first place lack.
Of course, just doing this would be illegal on most proprietary operating systems.