The problem with DOS Box, it that's a full blown emulator. You're emulating a complete clone of a PC (which take some performance hit, specially if you consider playing the game on a handheld device, where DOSBox still has a significant impact on battery life).
Whereas 2D game engines of the era aren't extremely complex and could be ported to modern hardware without excessive work.
2D platformer of that era don't have extremely complicated engines.
more or less, the only assembler parts and low-lever system calls you're going to see would be the graphics (mostly: gfx-mod init, drawing sprites, drawing tiles. so mostly a bit of bliting) and sound (playing the music. here it's pretty much low level, with music specifically written for hardware, like fm synthesis).
compare this to 3D engines (where big bunch of assembler handle drawing a whole 3D scene so tons of code, but music is using some 3rd party middle ware for midi playing).
Rewriting the graphics routine using SDL isn't that much complicated. It boils down to rewriting the 2-3 tiles & sprite blitting routine with modern SDL (compare to a 3D engine, where the best course is to scrape it and rewrite a different engine using opengl).
Music might be harder (probably the best course is to use an adlib emulation library).
I happen to have the necessary skill set (it's been a hobby of mine, both back then and now, both writing mine and hacking others') but I won't necessarily have the time
The point of having the source would be to easily port the game with SDL to any other platform.
Why should we have to resort to such shenanigans
Because Slashdot is US based and is english speaking, and nearly all the discussions here can there for fit within basic ASCII char-set. (Except a few loan-words which are acceptable without accented chars anyway).
The fact that you and I come from other regions and speak other languages won't change the fact that Slashdot doesn't give a fuck about non-english language and their scripts. Support for UTF-8 is not a vital necessity on
On the other hand, motivated people like me have found a compatible way around.
Also, given the avarage geekness here around, html entities don't feel that far stretched. Probably half the
very short glances at a control panel in realtively safe moments isn't an extraordinary risk.
And collision avoidance systems in modern cars (standard for some amnufacturer, about to be mandatory in a couple of years in EU) are definitely a help to make the "short glances away of the road".
Of course, such systems ARE NOT an excuse to do a lousy jobs and construct very distracting and attention grabbing interfaces.
BUT it's always reassuring to know that electronics can help making your travel a bit safe.
use HTML entities like "é" :
"cliché" give "cliché"
Yet, SSL handle only the encryption between a server, and the client application.
You can use the same encryption scheme for encrypting anything.
TLS/SSL is not an encryption scheme. It's protocol which defines how a client application and a server negociate an encryption. You can't use it for mush else.
AES is an encryption scheme, you could encrypt anything with it (an SSL connection, a ZRTP media transmission, password-protect an archive, encrypt a file with OpenPGP)
of course libraries like openssl will implement both (because what purpose would be SSL without actually being able to encrypt ?!) and other functionnality (S/MIME, similar to openPGP in that it use PKI for encryption, but instead use the same central authority model as SSL, instead of the web-of-trust model like openPGP).
Note that several Linux distribution also feature the same level of use simplification.
You just need to make key management easy. I know people are going to get angry every time I bring up Apple, but OSX can store certificates/keys in the keyring, which can then be backed up to iCloud {...} it's not impossible to make the whole thing much more automatic, safe, and easy for normal users.
I've never said it's impossible to make it better. But the user will always need some level of intervention (like at least caring that encryption happens, and checking that correct keys are used).
OTR basically works this way above any chat stream.
It's made entirely transparent, user won't notice that encryption is happening (I mean, unless they log into GMail and notice that the GTalk/Hangout chat logs only contain encrypted garbage).
The only required action from the user is running through a "socialist millionaire" identity confirmation.
It boils down to different trust models.
Trusting every involved government to stop indiscriminately spying on all its citizens require quite a leap of faith.
Encrypting between your correspondent and you doesn't require trust in 3rd parties like government or secret agencies.
Under this situation, having encryption anyway is always good in case that the gov decides to deceive you.
But yeah, I agree with you that achieving *proper* encryption isn't easy.
Now there's another effect: increasing usage of encryption increases (as I've said above) the cost of spying.
So use TOR even if it's just for pr0n !
Yep, have the same option in my ebanking interface too
(make an additional security to the "unusual pattern detected" approach).
You better hope that they have a regular battery in there and use the primary cell (yes, it's not recharging) as a range extender for those few trips that exceed the secondary cell capacity.
In this case, it'll be slightly better than those cars like the BMW and Volt that are primarily electric but tow a gas generator with them to offer extended range operations. This one keeps the existing simple low-maintenance electric drivetrain without having to add all the gas engine support components to the car.
Well that's exactly what TFA says:
car runs on the lithium battery.
when doing short trips like comuting between home and work ( typical everyday trips are 50 km according to TFA ) you simply run of the battery and recharge it at home/at work.
when doing long road trip, instead of stoping at a fast charging station, the alumium kicks in and is used to top the regular lithium battery.
Encryption isn't privacy.
Encryption isn't everything and all privacy.
But encryption is part of the solution, as much as Tor, etc.
your communications are going to be monitored without a warrant so they will be able to monitor all your associations, purchases, communications and movement and locations. Basically it is like having a tail on 24x7 with someone looking over your shoulder...
Perfect privacy will require several component. Encryption is one of the them. Connection obfuscation like Tor is another. Relying on pseudonymous identities (Do Not Track Me single-use email addresses, for example) is yet another.
then you are past the point where encryption will mean much since they can put a keylogger on your system or maybe even break your 256 bit encryption.
the 256 bits encryption is safe. the actual maths behind it have been repeatedly proven to be sound and secure.
getting the password stolen (keylogger, side channel, implementation bugs, etc.), on the other hand is likely to be what will happen. (and as both software and hardware is shown to be backdoored, they won't even need the effort of puting an new keylogger, just use the backdoors).
The only protection from the surveillance state is either to eliminate communications technology altogether or to return to the rule of law.
In the mean time, you can also make the surveillance job as difficult and expensive as possible.
Thus: encrypt and obfuscate as much as possible, even for trivial everyday activities.
A lot of sites encrypt their traffic with SSL.
Yet, SSL handle only the encryption between a server, and the client application. (and can be made totally transparent to the user).
Whereas the anti-surveillance discussed here are end-to-end (from one user to the other) and will always require some minimal end-user intervention (key handling, although the interaction can be minimized and user interface efforts can make the experient as easy as possible).
(Facebook/Apple Messengers, Google Hangouts, etc.).
Note that OTR (Off-the-Record) is standard, and is capable to be used above any of those, just like OpenPGP works over email.
But again, this requires either using full blown clients (pidgin, adium, jitsi, messagebird, or any other OTR compliant client) or using extensions (like cryptocat) to be able to use it from within a webapp.
Also, for obvious reason, OTR disturbs the "search" fonction on chat web-apps (as the webserver only sees encrypted text and can't search).
A text whenever your credit card was used saying "Card with number ending in xxxx was used in location yyyy, if this was a fraudulent charge reply to this text" would work just as well without the privacy issue of tracking locations.
As currently done by several other banks.
(I'm in europe)
Tried that. They still blocked the card after my first transaction abroad.
Then tell them to go fuck themselves and switch to another bank.
Mine (europe) not only support that, but its directly accessible from the e-banking web interface, so you can do it at any time conveniently and quickly.
Any program which runs right is obsolete.
