Sitwon

Java does often fall short of C++ in real-world benchmarks, however not by a whole lot. It's biting at the heels of native-compiled C and C++ and still out-performs some native-compiled languages (eg, GNU Common Lisp). Compared to dynamic or interpreted languages, Java's performance is essentially equal to C or C++. The small performance penalty of Java has more to do with the baggage of it's object model than it does with the optimization of the machine instructions. Java necessarily uses more bytes of memory to represent objects than is typical of the idiomatic C++ equivalent. Regardless, Java is an old VM which still carries a lot of historical cruft. If you look closely at some of the optimization techniques of a more modern VM such as HipHopVM I think you'd be quite impressed with what can be accomplished, even compared to idiomatic C++. As for Pascal... Pascal Strings were a terrible idea, as were several other "features" of the language. There has been a lot of valid criticism of Wirth's ideas over the intervening decades. Just as with VB, I'm struggle to see any valid use cases where it's the "right tool". Especially given all of the modern languages we have to choose from. I acknowledge that it is a capable language, but with so many better options why would you ever prefer it? Just my opinion, I suppose.

Two things here... 1. Why Delphi/Pascal? Isn't that a dying language? What benefits does Pascal have over any other language? 2. Mature VMs actually tend to out-perform native compiled binaries. It seems counterintuitive, but a good just-in-time compiler (JIT) can optimize the code better than a static compiler because it can take into account actual run-time statistics and trends in the data which the static compiler has no ability to predict. That's how Facebook was able to make PHP fast enough to run one of the most sophisticated and heavily-trafficked web applications on the Internet. (See: HipHopVM)

You're better off with OLSRd than batman-adv. There should be an olsrd OPK in the repository already. Start there.

I'm surprised there is more discussion about XP's slow and unnecessarily drawn-out demise than there is about Heartbleed on these forums. http://heartbleed.com/ https://forums.hak5.org/index.php?/topic/32297-ladies-and-gentlemen-start-your-scanners/

Well as I said, the protocol is pretty open. Open enough that you can poke at it with already ubiquitous terminal emulators. It takes a little bit of research into what the codes mean, but that's not a huge burden for the average Linux geek. Couple that with the fact that most geeks will only care about doing this once or twice on their own vehicle and it's not hard to see why nobody ever went to the trouble of building out a whole application around it. If you want a fancy graphical interface so you can just click buttons without having to learn or think about what you're doing, write it yourself. Or at least use Google. I found these in one search: http://sourceforge.net/apps/mediawiki/openobd/index.php?title=OpenOBD http://www.obdtester.com/pyobd http://freediag.sourceforge.net/

As I understand it, the OBDII protocol is pretty simple. If you get a simple serial scanner you can poke at it with any terminal emulator attached to the correct serial port.

I have been gaming on Linux for over a decade. Back in 02/03 I would take my Linux rigs to LAN parties, and nobody could tell the difference when you were in-game. Wine was pretty good back then. It's still pretty good. People like to harp on its occasional failings to make it seem like it's buggier than it actually is. The Linux games in Steam are native Linux games. Many of them are also available as stand-alone Linux games through their original developer/publisher. However, it's also worthwhile to have a copy of Steam running in Wine to play the games that haven't been ported over yet but run just fine. The Humble Bundle Store is a good spot to find native Linux games.

http://www.google.com/nexus/5/

I believe airdrop-ng is the specific tool that does what you're describing.

Unless the software is just sending the encrypted hashes from your registry in the packets, it must first decrypt them in memory in order to authenticate with the cameras. So you should be able to attach a debugger to the process and sniff them out of memory. How to use a debugger is outside the scope of this response, but I'm sure you can find resources online to help you if you decide to go down that path. In either case, the first step is to see what you can sniff with Wireshark. It may be that the username and password are being sent in plain text, or only weakly hashed. Alternatively, you could try a dictionary attack against the cameras.

Could someone have created an alternate crypto-currency for that purpose? Yes. Would such a crypto-currency gain enough of a following to do any better than stealing free compute time on Amazon EC2? Probably not. Could someone have infiltrated such a feature into BTC or LTC or any of the top 5 crypto-currencies? No. Could someone have in some other way figured out how to take advantage of these existing hashing networks to weaken existing encryption or password standards? It's mathematically unlikely, but I suppose it's a possibility (if they also managed to solve some other challenging, unsolved problems in mathematics.) In short, there is no evidence to suggest that such a thing is happening, and the math (as Bruce Schneier says, trust the math) strongly suggests that observation of the the output of the Bitcoin hashing network would give you little if any useful insight toward cracking passwords or encryption standards.

If you ssh to your Mk5 and check the route table (`route -n`) you will see that by default it's got a gateway route for 172.16.42.42. If you want to change the IP of your PC's IP and have the Internet continue to work for your Mk5 you will need to update the route table to point to the new gateway address. # route del default gw 172.16.42.42 # route add default gw 172.16.42.2 Also make sure that /etc/resolv.conf points to some actual DNS servers (or to your PC) so you can resolve domain names.

While there is still some room for innovation, there's very little benefit left that you could squeeze out by creating a whole new OS from scratch. Remixing Linux into new distributions is what most companies do when they need a "custom OS", but that's basically what Linux was designed for and the pathways are well-trodden. There's room for innovation in most of the layers and components of a Linux system, but it's all well documented and well understood. Tough to create much of a competitive advantage in that arena. Some processing will always be done locally, but what's happening is that the local OS is just becoming a VM host and the local code is targeted to the generic VM rather than the specific underlying system. So nobody is really paying attention to the underlying OS anymore, instead they pay attention to the VM that their applications are targeting. That VM, in many cases, is the web browser. However, the last thing we need right now is yet another web browser to toss their hat into the ring and create yet more quirks that web developers need to compensate for. So if you're harboring any ideas about creating a new web browser... just don't. Well that depends on what you mean by "real programs". With apps running in a mobile OS or newer web applications running in the browser I can do almost anything and everything that I could do with the native utilities of my host operating system. There are still a few rare exceptions, but they are becoming increasingly rare (especially with HTML5). I don't look at it pessimistically. What that means is that application developers and write to one target platform and support a broader spectrum of users than ever before. I can write an application in HTML5 and it will work on Windows, Mac, Linux, phone, tablets, smart TVs, wrist watches... all without having to do anything special in the source code or touch a cross-compiler or worry about endianness. In a lot of ways, that's a victory for Linux users, for developers, and for end-users.

I have so many responses to this I'm not even sure where to begin. First of all, writing a complete OS from scratch is not just hard, it's extremely time consuming. All of the desktop operating systems you see today are the result of the hard work of dozens or even hundreds of people over the course of 5 - 10 years. If you want to re-invent that wheel, get ready to settle in. You can start off by reading this introduction to computer science: http://www.amazon.com/The-Elements-Computing-Systems-Principles/dp/0262640686/ Then learn a bit more about programming with some of these resources: http://sitwon.github.io/learnproglang/Home.html You'll need to know assembly: http://www.amazon.com/Art-Assembly-Language-Randall-Hyde/dp/1593272073/ And also compiler design: http://www.amazon.com/dp/0321486811/ And many many more topics. Just getting up to speed will take you about half a decade, but it's doable. If all that sounds like too much of an investment, you can do what Mark Shuttleworth did and just build on top of the work other people have already done. You might want to give Linux From Scratch a try, and learn about how the pieces of a typical Linux distro fit together and how you can design your own custom distribution. http://www.linuxfromscratch.org/lfs/ There's no shame in bootstrapping your new OS on the underpinnings of an older OS. Shuttleworth did it with Ubuntu, Google did it with Android, Apple did it with OS X (on top of FreeBSD and NetBSD). Even Microsoft did it originally when they bought DOS. It's a quick way to get something tangible going, and then you can work on replacing individual parts slowly over time. To get started, you'll just need to know some Bash: http://tldp.org/LDP/abs/html/ It helps to also know enough of C, C++, the compiler toolchain, and build systems like Autotools to fix the trivial build errors you WILL encounter along the way. http://www.amazon.com/C-Programming-Language-2nd-Edition/dp/0131103628/ http://sitwon.github.io/learnproglang/Home.html http://www.amazon.com/Definitive-Guide-GCC-Guides-ebook/dp/B001GNBTY6/ http://www.gnu.org/software/make/manual/make.html http://www.amazon.com/Autotools-Practioners-Autoconf-Automake-Libtool-ebook/dp/B003WUYEL6/ But really, as much as you think you want to start a company that will compete with Apple and Microsoft... you don't. You're already too late. Even if you came out with some revolutionary new OS tomorrow, it just wouldn't matter. There are so many reasons behind this, that I could spend the entire day explaining to you why that window of opportunity has closed, but to boil it down really quick: desktops are done. The Year Of The Linux Desktop will never happen. Even as Linux is growing in popularity, desktop operating systems are becoming increasingly irrelevant. Application development is continuing to trend toward fatter and fatter web-applications, and desktop operating systems are increasingly just a light dressing on top of the REAL computing environment: the web browser. By the time you've finished filling out paperwork to incorporate your shiny new company, another million prospective customers will have switched from their old desktop operating system to ChromeOS or FirefoxOS or a tablet running apps which are mostly just thin interfaces over an HTML5 webapp. Desktops are done. Their time has come and gone. Jumping in a the tail would mean competing against the entrenched veterans for an ever decreasing user base. One which is mostly comprised of the die-hard fans of those very operating systems you wish to compete against. So you'll have a steep up-hill battle to win them over, and ever decreasing reward for doing so. I'm not saying it's impossible, I'm saying that it's never going to be profitable. Even the big players you're looking to compete against can't make a profit on their operating systems, that's why they're all branching out into other markets. They're losing money on their OS development efforts, but it enables them to sell other products and services. That's the cold hard reality, and that's just one of dozens of reasons why a new OS is going to have a very VERY hard time competing in the current market place.

Your syntax looks correct to me. Is that the exact source code that is giving you trouble? three questions: 1) why do you have a semicolon at the end of the first line? 2) why are 'if' and 'elif' indented relative to the first line? 3) have you verified that you're not mixing tabs and spaces for indentation?

That looks like it's probably another typo in your input, however the duckencode application should be giving you a better error message. If you can point me towards the source code, or failing that the jar file itself, I can audit the code and perhaps improve the error messages to be more meaningful.

Have you guys seen this thing? http://tech.woot.com/offers/maxell-airstash-wireless-flash-drive It's sort of like the reverse of an EyeFi device. Seems like a platform that is ripe for hacking. Does anyone have one?

Using GnuPG (or some variant there of) is currently the most trusted methodology. By default GnuPG will use RSA which is an asymmetric (public key) cipher. However it also has options for encrypting files using various symmetric key algorithms. Symmetric keys are generally perceived to be less secure because of the difficulty of exchanging the key securely and keeping it a secret. If you have a strong key and you can keep it a secret, even the XOR algorithm can be nearly impossible to crack. (Especially if you never reuse the same key.) There are other asymmetric algorithms besides RSA, notably the ones based on elliptic-curves. The Snowden leaks have indicated that certain elliptic curve algorithms (or perhaps just their implementations) may be compromised. However there are others which are believed to still be secure. The reason elliptic curves are important is because it is believed that RSA will become obsolete within the next decade or two, however elliptic curves may remain secure for longer. (These predictions are based on the specific math problems that each method relies on to make it mathematically difficult to break the crypto, and progress which is being made in academia toward solving those math problems with better speed. If you're interested in the specifics of the math I can link some introductory explanations to get you started.) The take away is that RSA is secure enough for now. EC is currently the best candidate for the future. And if you can secure the key exchange, then XOR is all you need.

Use rsync with the '-P' option. It will allow you to resume the transfer if the connection fails instead of having to start over from the beginning each time.

Not to give too much away, but my Mk V just arrived today and I'm working on something special for the use case you describe.

Based on your description it sounds like you have something like this: D:\ D:\Dir1\ D:\Dir1\Dir00\ D:\Dir1\Dir01\ D:\Dir1\Dir02\ ... D:\Dir1\Dir98\ D:\Dir1\Dir99\ And it sounds like you want to achieve something like this: D:\ D:\Dir1\ D:\Dir1\Dir99\ D:\Dir1\Dir99\Dir00\ D:\Dir1\Dir99\Dir01\ ... D:\Dir1\Dir99\Dir98\ It doesn't make a lot of sense to me why you would want to do that, but that's the best that I can understand your description of the problem. The batch script I gave you as an example will allow you to do this: D:\Dir1> mv.bat Dir00 Dir01 Dir02 ... Dir97 Dir98 Dir99 That will move Dir00 through Dir98 into Dir99. Specifically, it will move each path specified as an argument into the path specified as the last argument. However, it still requires that you manually type the name of each directory which you want to move into the target directory. If the names of the directories you want to move are numerically incremented (as in this example) then you can use a FOR loop to move each one individually. D:\Dir1> FOR /L %i in (0, 1, 98) do move Dir%i Dir99 Of course, that loses the zero-padding which I earlier specified in the example. So here is how you would do it with zero-padding. D:\Dir1> FOR /L %i in (0, 1, 98) do ( > set "num=0%i" > set "num=%num:~-2%" > move Dir%num% Dir99 > ) TL;DR: Stop trying to do anything sophisticated with CMD and install a Borne-compatible shell (like BASH) on that system. Either MSYS or Cygwin would be good options. MSYS is included when you install MinGW or Git. As a last resort, I suppose you could install PowerShell and learn how to use it.

I'm pretty sure the episode you referring to was about doing poor-mans two-factor authentication. It also seemed redundant with PAM, but I think they were just too lazy to read the docs for PAM. http://usbauth.delta-xi.net/doku.php

Write a batch file. Something like this: https://gist.github.com/Sitwon/7214492

Generally, I think you'd be better off asking the author of Mailvelope. According to their website, they have support for Firefox in development, try looking here: https://github.com/toberndo/mailvelope/releases

And of course working on this sent me down the rabbit hole of randomness and entropy generation. I just wrote a SlackBuild for rng-tools so I can seed /dev/random with the TPM in my laptop. Has Darren ever tried to explain entropy on the show?