Hacker Newsnew | comments | show | ask | jobs | submit | gsnedders's comments login

Transcription errors are very much a problem, though, especially when you're dealing with faded or smudged ink.

Scanning the images allows people to verify the transcription and to distribute the work of doing the transcription.

reply


> While the rotary did won Le Man 24 hr endurance race, it is still plagues with problem.

Well, they were given dispensation to run 170kg lighter than any other car in the class (830kg v. 1000kg). It's likely that that made the deciding difference in their win.

Also, it's worthwhile remembering a lot of the fuel efficiency problems with rotaries are avoided by running at a constant, relatively low RPM. For a generator motor, they make a hell of a lot of sense. Sealing the chamber is also a lot easier at a constant RPM, which should help with oil consumption and reliability.

reply


Traditionally access to the data has been sold; making it public loses that income.

reply


There's a wrapper for CPython to get it to implement the tracing code, afl-python[1]. Alex Gaynor did a basic intro to it a few days ago which is a better write-up that the project itself has! Of course, this doesn't work so well with mixed C/Python code.

[1]: https://bitbucket.org/jwilk/python-afl [2]: https://alexgaynor.net/2015/apr/13/introduction-to-fuzzing-i...

reply


Google have done a lot of studies to try and reduce the number of click-throughs of TLS warnings, especially when it comes down to the wording of the message.

-----


I don't mean they should present the message to all users. Currently, even if you go into the certificate details without being prompted, there is nothing there saying anything to the effect of "SHA-1 is insecure; if you are the webmaster, get this certificate issued with SHA-2"

-----


> There's nothing magical about the 4 walls of a college campus that bestows special compsci knowledge.

There's a few things that make them good — most notably, the support available if you don't understand something well. While certainly there's a fair amount of support available (esp. online, and depending upon your corporate culture possibly at work as well), I'm yet to find a community that's as willing to help people understand material as many teaching staff are, especially when it comes to more obscure material.

-----


It may just be the present college generation, but future generations will not hesitate or have issues getting into communal learning groups online to study similar topics without the need for a centralized instructor, especially when that instructor leaves them a hundred grand in debt.

Today, there is everything from IRC channels to mailing lists to forums to subreddits to facebook / g+ groups to linkedin groups to get involved with other students of the same topic, maybe even with a few veterans to provide guidance, to learn these subjects.

You won't find people that lecture you, but you will find people that will answer questions. I'm surprised there isn't an SO for that yet...

-----


So how does TM make money? Where is the cut for venues taken from? All from the booking fee?

-----


WebKit actually has quite a lot of fairly nice, simple easy-to-read C++, especially around the DOM. Or at least did a few years ago, and I believe it's still mostly the case.

I remember asking for advice years ago where to cut my teeth on C++ and getting suggested WebKit by several — and people who weren't trying to lead me massively into a pit of doom. (Admittedly, I've still practically never contributed to WebKit, and I ended up doing my first larger bits of C++ on Presto. But hey, I've still read plenty of WebKit code over the years.)

-----


One nice—and, I think, underappreciated—thing about Servo layout is that the parallelism forces you to organize your algorithms cleanly. Unlike every other engine, render objects in Servo are not responsible for laying out their children recursively; the higher-level parallel traversal driver does that. That means that you must write your layout code in such a way that the right information is available at the time the traversal invokes your layout method. You are also limited in what you can access: your render object can't access your parent (because that would be racy), nor can it access the DOM (because we can run layout off the main thread). This requires a fair bit of up-front thought, but once that's finished it's easy to read the resulting code, because the layout code is grouped into specific functions ("assign-inline-sizes", "assign-block-sizes", and so forth) that do just one thing. This goes a long way toward making layout easier to understand, especially when it comes to complex situations like tables.

-----


Right — and it's hardly surprising that Servo's codebase is in many ways nicer than existing browsers (both because of the inherent separation parallelization causes, and the lessons learnt from existing browsers). And given layout has always been arguably the worst part, it's hardly surprising that Servo shows good gains there.

-----


And there's some deal with Panasonic for the Gigafactory as well — it sounds very much like it'll be manufacturing stuff that's basically Panasonic IP to start with.

-----


Note that WebKit/Blink are very unlikely to change their behaviour to be more interoperable/sane if it ever gets standardised because so many of their tests rely on it, and making sure all the test expectations stayed valid while updating it would be an enormous amount of work. (Lots of their tests load a webpage, take the innerText of it, and compare that string with an expectation.)

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: