HN user
Link to paper: https://www.usenix.org/system/files/conference/osdi16/osdi16...
I'm one of the co-authors on the paper. Let me know if you have any questions! (And no, we didn't come up with the title of the article. One of the Columbia journalists did.)
I'd just like to point out that `cryptography' is _not_ just about testing that `decrypt(encrypt(msg)) == msg`. memfrob'ing a region of memory does this, but would we consider that a 'secure' encryption scheme? I don't think so . . .
Even if it was -- how do you unit-test a PRNG to ensure the output is uniformly random? How do you ensure you don't have collisions in a hash function? How can you ensure that there's no replay attack on your protocol? How can you use unit-testing to demonstrate that there is no hole in your protocol like, say, when the Germans repeated the key twice at the beginning of the message while using Enigma?
These are all very real and valid cryptography concerns. Sorry if this sounds snarky, but in all seriousness -- I'm very curious as to how you would unit-test these.
Just reading your second reference, the bit about expert systems is pretty interesting . . . what's your stance on this? It seems that, given sufficient instrumentation information, one could probably construct a fairly decent expert system that might be able to shed some light onto these sorts of problems. (Keep in mind the fact that I'm still very much a junior software developer!)
The example of FDs from the original article seems like a good one; a properly developed expert system might have been able to notice a lack of changes in the current software environment and suggest looking elsewhere. (Problem is, if I got that response from my automated problem-solver I'd just ignore it and keep looking . . .)
So, any insightful points to crush my youthful idealism? :)
Speaking as a student studying systems (particularly security and OS development) . . . the second point sounds really interesting.
Recently I've been working on a simple microkernel (called Sydi) that should actually make this possible. It's a distributed system straight down to the kernel: when two instances of the kernel detect each other running on a network, they freely swap processes and resources between each other as required to balance the load. This is a nightmare from a security perspective, of course, and I haven't figured out the authentication bits yet -- too busy working on an AML interpreter because I don't like ACPICA -- but that's not the issue here. (It's far from finished, but I'm pretty confident that I've worked out the first 85% of the details, with just the remaining 115% left, plus the next 95% of the programming . . .)
Due to some aspects of its design (asynchronous system calls via message-passing, transparent message routing between nodes in the network, etc) I feel that it will be entirely possible to take a snapshot of an entire cluster of machines running the kernel. It would be expensive -- requiring a freeze of all running processes while the snapshot is taking place to maintain any level of precision -- but I'm confident I could code that in during the space of a week or two . . .
I haven't thought much about what kind of analysis one could do on the instrumentation/snapshot results, though. I'm sadly too inexperienced with `real-world' systems stuff to be able to say. Anyone have any suggestions for possible analysis avenues to explore?
This is exactly my take on the Parallella board, and it's the exact reason why I donated to the Kickstarter back in the Fall.
I want to try my hand at writing a real, efficient, many:many message-passing API on top of SHM. It's something I've been interested in for a while (and am doing in an a side project for x86_64). Not because it hasn't been done a thousand times before, but because it's neat.
I want to write a compiler for the Parallella. Not because there aren't compilers already, but because I've never written a compiler that targets a RISC architecture before. I've never written a compiler that respects pipelining.
I want to write a parallelized FFT based on the original paper for the Parallela. I've used various FFT libraries before, but never actually implemented an FFT straight up. Why? Not because it's never been done before, but just because it's an idea that appeals to me. And for practice parallelizing algorithms . . .
I want to write a raytracer for the Parallella. Not because I haven't written a raytracer before, but because I think that I'll be able to do something interesting with a Parallella raytracer that I haven't done before: real-time (ish) raytracing. Not because that hasn't been done before, but because it'd be neat to build.
I want to build a distributed physics engine. Not because there aren't excellent open-source physics engines (Bullet, ODE, etc.) -- but because I find the problem interesting. It's something I've wanted to do for a while, but never got around to. Why? Because it's interesting.
I could go on, but I'll stop here. The Parallella, I think, is a catalyst for a lot of small projects that I've wanted to do for a while. The Parallella is my excuse to spend time on random projects that will never go anywhere beyond a page on my website describing what they are, plus a link to the source code.
And, you know what? That seems perfect to me. That's why I want a Parallella, and that's why I'm eagerly awaiting mine within the next month or three. (Hopefully!)
I've been using Lua in a project for quite some time, replacing Python as my embedded scripting language of choice.
It never ceases to amaze me, as a language and as an interpreter. Sure, the syntax bites you occasionally, and sure, the lack of built-in functionality is occasionally annoying. But hey, I can add callbacks into a simulation engine that execute 10 million times per second with almost no slowdown in the result. Like the article mentions, the string matching library isn't as powerful as Perl's, but it's more than adequate for all of my uses.
My only wish is for an updated LNUM patch that works with Lua 5.2. I deal with integers too much in my projects for its absence to not be annoying.
Same thing here. When reading fiction (and some types of non-fiction) I can do away with my internal monologue and absorb the text directly, with full or near-full comprehension. [0] With textbooks etc. I need to actually subvocalize the words for full comprehension.
I'm skeptical of the claim about subvocalization made here as well, but I'm realistic enough to know that I'm not different enough to fall outside the realms of the study referenced.
[0] My reading speed in this `mode', so to speak, ranges from 300-750 WPM, depending on how engaged I am in the material. I measure comprehension by testing myself via asking others (with a copy of the material in question) to quiz me on the content after such a reading session.
I've found that my impression of CtrlP's speed varies dramatically depending on the project that I'm working on. For projects such as Bochs [0] (~750 files in CtrlP), I get annoyed at the initial .5-sec wait [1], but after that it's extremely fast. I don't have a particularly fast processor, either.
I find CtrlP breaks down with large projects such as the Linux kernel. While it's fast to find the initial list of files (2 seconds or so) it's extremely slow to actually search through said list, about .5-sec per keystroke.
[0] I'm not a maintainer, I just happen to be using its wonderful instrumentation hooks in a research project.
[1] It's about half a second on my laptop, which has an SSD. This time is dramatically larger if you have a rotary drive, more like 10-20 seconds IIRC.
Regarding the company in question -- my own best guess would be one that does static code analysis -- Coverity [0] comes to mind, for example. I can't really think of any other companies that would benefit greatly from having a large stock of employees that all know the C++ standard intimately. Except of course for those that write compilers, but as you say, there aren't many of those around.
From the article:
> An updated version of LAN Manager known as NTLM was introduced with Windows NT 3.1. It lowered the susceptibility of Windows passwords to rainbow table attacks, but didn't eliminate the risk. To this day, the authentication system still doesn't apply cryptographic "salt" to passwords to render such attacks infeasible.
Is this true? Do WinNT-derived systems _still_ not use password salting? If that is the case, my opinion of Windows's security just dropped quite a bit. I know security can exist without salting, and I've not done any in-depth Windows development, but from experience w/backend dev and Linux dev it seems like it'd be pretty cheap to add . . .
... you'd need some preprocessing first. The ASCII characters `0' and `1' aren't easy to use to write a program, though you could do it with nasm and some '-' and '+'s I suppose.
If someone can prove me wrong, I'd be very happy though. Writing a program using just '0' and '1' (the ASCII characters) would be awesome. (in an established programming language, and no homomorphisms. :) )
> Kids aren't learning abstract fundamentals at that age though. They are mimicking stuff.
I have to respectfully disagree with you on this point. A member of my extended family does extensive work with deaf young children (aged six months to six years). Her job is to accelerate their spoken-language development, which has been delayed by virtue of being deaf. She repeatedly makes the point to me that the difference between children with delayed language (e.g. most of those she works with) and a "normal" child is that those with delayed language tend to not understand (or use) abstractions in their speech. They treat each word as if it has a single application or use. Once they understand that each word actually can have multiple applications, their ability to learn new words grows exponentially. Until that point, they are simply mimicking.
That sounds like an abstract fundamental to me, though I am perhaps mistaken. (This is also subject to a counter-argument about the nature/nurture aspect of language, e.g. do we have an inborn understanding of language.)
Also, on a more personal note: by the time I was five, I was experimenting with electrical circuits. A few 1.5V flashlight bulbs, a pair of switches, a few D-cell batteries, and some wire went a long way. I taught myself that you couldn't put lightbulbs after each other and have them light up to the same brightness (e.g. series resistance), but that you could connect them in parallel without any of those effects (these were short-term, so I didn't notice the extra power draw). Likewise for switches -- if they were in parallel, then breaking one was enough to break the entire circuit. Those are brand-new, abstract concepts that I was, as you say, internalizing in an intellectual sense.
And no, I wouldn't have called my IQ particularly high at the time, and I still would not.
zsh used to do this for me (back when I used it; switched back to bash about a year ago now), and it was the most _annoying_ thing it ever did. My typical workflow (when working on a software project) involves a pair of terminals for compiling and execution, an editor window (whether gvim or kate/kile/kdevelop etc.), and a documentation terminal for manpages.
Oftentimes my execution lines are somewhat long -- enabling/disable debugging info in certain sections of the program while tracing programs, etc, and I'd not want to type them out continuously. As a result I'd use the command history a lot, muscle memory would automatically hit CTRL-P once I switched to one of my execution terminals. If I'd visited something in the documentation terminal in the meantime, I'd be staring at 'man 2 timer_create' instead of my expected './aesalon --set listen=6421 --set ::debug-shm --set ::debug-interaction'. The third-second or so I'd need to do a sanity check would seriously interrupt my train of thought.
It's neat, and I can see why people like it. But for my particular one use-case of terminals/shells, it was annoying. Took me about a week before I realized just how much it was slowing me down and disabled it.
[I probably should have just set up another zsh configuration for those particular terminals, but enough years with bash have trained me, I guess, to not expect it from my shell.]
Actually, it's not that difficult. Get GCC to generate DWARF [debugging] information, and then use that to provide the back-references. (Reference: DWARF 3.0 spec, available at http://dwarfstd.org/doc/Dwarf3.pdf. See page 92.) This is how GDB does the same.
The output is a little weird (I've had it execute line 56 before line 55, for example) and you do have to be careful, as not all lines translate directly. But it would be at least be a nice starting point. There are even some nice libraries out there that parse this information!
EDIT: Hmm, I just noticed that the source is on Github. If I get some time this weekend I'll try adding support for this.
I had the same thought about the download link -- it does seem a bit odd.
But if you think about it, it does make sense. Very few people will not have JavaScript enabled -- those who do will be web developers or other technologically-minded individuals. I'm sure this is not exactly valid, but . . . it seems to me, at least, that a lot of the time this sort of person is going to be using either Linux or an Apple system.
Between the two, AFAIK, a Linux system is far more likely to have git installed already. If not, most would probably want to install it via their distribution's package manager (as the Linux download page actually directs you to do). So it does seem a semi-logical choice.
Personally, though -- I would have fallen back to a list of download links for different platforms.
It is perhaps worth noting that 12/24V DC is just as deadly as 120/240V AC. There's naught deadly in voltage, it's the wattage that electrocutes you. A static shock is 6kV, as I recall, but the amperage is low enough that it doesn't hurt at all.
I'm a little sketchy on the details (been a while since I studied this sort of thing) but I can personally attest to losing muscle control in my right arm on a 6V circuit using only a standard (1Ah?) alarm battery.
I haven't had my DNA sequenced (yet!) so I can't answer if I'm human or not. I suspect I am, though, and simply had the good fortune to be given parents willing to foster an interest in scientific and mathematical subjects.
How quickly time flies . . . I started programming on paper, writing programs for PIC12 microcontrollers. I would have been seven at the time. Never actually programmed one of the devices, but the experience taught me to logically think through a task, break it down into discrete steps, etc.
I quickly progressed to writing QBasic programs on paper, reading through some textbooks my parents borrowed from the local University library. From there I purchased a copy of `Computer Programming for Dummies' and started programming simple programs in the shareware version of Liberty BASIC [0] -- do you know how _frustrating_ it is to be limited to (IIRC) 100 lines of code?
From there, I taught myself C and C++ (via the a Dietel & Dietel textbook on the subject) and Python via another textbook that I don't recall the title for. I started programming games in DJGPP/RHIDE, and grabbed a copy of Michael Abrash's Graphics Programming Black Book that I never understood for the next five years or so . . .
I learned some basic concepts of data structures when I was twelve or so . . . around then I implemented my first binary tree. I'd been writing hash tables/linked lists before then, but never realized that it was a pattern. Just me reinventing the wheel as usual . . .
When I was fourteen I finally got my act together and wrote a simple card game for the OLPC XO, my first open source program. I doubt it's still around, but it worked! Crazy Eights goodness . . . my first Python program that reached more than 150 lines -- as I recall it topped out at about 750 or so. Not terrific, but it was an accomplishment.
I moved on to more theoretical topics after that; I spent the next year or so teaching myself how to write a recursive descent parser and write an interpreter. I learned quite a bit about trees and CS theory from that, to be honest! I can recommend the process to anyone who's interested -- writing an interpreter, including the parser, from scratch is _definitely_ one of the better things that's happened to me. That project, topping off at about 2,250 lines of C++, also taught me something incredibly important: the importance of designing something properly. My first introduction to software engineering, I guess.
I spent the next while tinkering with random things, until I started my next major project, Aesalon, a month or two before my sixteenth birthday. I worked on it for the next eight months or so, and it topped off at about 17,000 lines of C++ before I started rewriting it.
Aesalon is actually, IMO, a pretty impressive project -- it's definitely one that I'd hesitate about starting nowadays. It was originally a dynamic memory watcher, using binary injection to insert some profiling code before and after each call to `malloc`, `free`, `realloc`, and `calloc`. It definitely taught me a lot about how Linux loads and executes programs; I ended up essentially writing the backend for a debugger (including break/watchpoints, reading the symbol table, parsing ELF headers, the whole shebang) and even wrote my own Qt graphics canvas (the stock Qt graphics canvas doesn't work very well past 100,000 objects, and I needed to display 1,000,000 . . .)
It was also an education in software engineering. Designing a system of that scale taught me a lot; I reinvented the observer design pattern, the visitor pattern, and about five others. I had to deal with pool memory allocators, ugly codebases (all my own fault), refactoring, and APIs. It's definitely the biggest project I've ever written, and I'm still working on a rewrite of it; the project page is up at [1] if you're interested.
I'm eighteen now, just finishing up my second year of University (studying computer science and mathematics), and . . . it's scary to realize that I've been programming for more than half my life. Longer than some people around me have been doing long division for.
Anyhow, thanks for the trip down memory lane. I haven't revisited a lot of that in a while.
Happy hacking!
Simple in concept, difficult in execution. How would you recommend the transition between the two systems be handled?
I believe that is the purpose of the AltGr [0] key, is it not?
How are they planning on powering these devices? The original article doesn't mention . . .
Solar seems the most obvious choice (to me).
That is per watt of peak power production.
I have some experience with solar energy at the small scale (1-2 kwh arrays) and I can say that at the consumer level, the cost for a solar array is now dropping to roughly $0.50/watt. It's still nowhere near the scale/cost of nuclear/coal but it's definitely more feasible than it was ten years ago.
Using the figure of $0.50/watt, to construct a 50MW plant would cost $25 million for the panels alone; bring in the infrastructure, mounting, and remember that the panels lose roughly 10% of their capacity every ten years. Plus account for cloudy days (not as much of an issue in, say, Arizona) and you start to realize that solar isn't a very viable option.
It works really well at the consumer/personal/business level but fails horribly at large, centralized setups. For those about to mention the `good sunlight' requirement, I will provide some refutation for that: my panels are located such that there is a good 30-degree angle to the east the sun has to peak before the light reaches them. The only time that power becomes an issue is the three weeks either side of the winter solstice; at which point I have to start watching my power consumption and regulating computer use etc.
I've assembled the array (roughly 1.5KWh) over the past ten years or so; the cost has been small considering what the equivalent would have been to purchase electricity from the power grid.
I have rambled on for quite a while here, for which I apologize. I guess the TL;DR version is: I don't think solar is feasible at large scale, but it seems to be at a small scale in my own experience.
Or at least, don't use blocking TCP calls if you do. Timeout and fail gracefully . . .
I've been using this for a while now (not sure where I got the original link -- it may have been the previous HN post).
I find that for common symbols, it works _beautifully_. But for symbols that can be drawn in different ways (consider \cupdot for example), it seems to bork and return unrelated symbols.
One thing that I would find quite interesting is someone writing something similar that, instead of using gesture recognition uses image comparison. I realize it would be quite difficult, slow, and probably would have terrible accuracy, but meh . . . I should try that.
Agreed, but note that the original webpage actually states: > So we have achieved our goal of calculating 100,000,000 million places of π in just under 10 minutes!
Thus it's not entirely the submitter's fault. But they should check what they're typing/copy-pasting! :)
Which is too bad, because I wanted to know how they were calculating 100 trillion digits in less than ten minutes . . .
I'm a current UCalgary student, myself.
As far as I am aware, the most major impact of this decision will be the abolition of the "nickel copiers", which allow for the copying of a certain percentage (10%, I think?) of any copyrighted work if you are a UCalgary student. I am uncertain of how the restrictions applied to professors & faculty.
I personally doubt that this will have much of an impact on my own career at University. I am not enrolled in a program that makes heavy use of such copyrighted materials, and thus far my use of said copyrighted material has been limited.
I think Access Copyright had it coming. For a very, very long time.
Now that, I must agree with.
Personally, I would be more concerned if someone with malicious intent and the ability to keep silent about what they have done had found & exploited this. [0]
Advertise: remove your competitor from Google's search results for a day! If I didn't think it was illegal, I'd probably pay for that, were I in such a situation.
[0] If, of course, it even existed in the first place. It seems plausible enough to me, even if I think it unlikely.
> (open source, actually, I think, but I'm not 100% sure)
To quote from the "introduction" dialog [0]: "Hundreds of free, open-source fonts optimized for the web".
Looking further, the "about" page [1] provides a bit more information: "All the Google web fonts are open source. That means that you are free to to use them in any way you want, independent of whether you're working on a private or commercial project."
I'm not sure what license they're using, though . . . I can't find anything but Google's standard "terms of service" license anywhere on the site.