> There are other ways to lessen the CVE workload.
> 1. Disable unused components with defconf or make menuconfig.
+1 for avoiding vulnerabilities, but were you saying this lessens the CVE evaluation workload? I'd love to hear about automation for evaluating CVEs based on a kernel config. I've done a fair amount of that manually and I'm not aware of any metadata in the CVE records (or in the CVE json in gregkh's new vulns repo) that includes config metadata.
In 2004 I tried integrating the RA into OS X via the Input Manager mechanism, a way to load external code into Cocoa apps that'd have access to the contents of any text field, so you could get the text that the user was currently looking at and send it to the RA for queries.
If I recall correctly, I never had enough time to make it very useful, and it wasn't clear how best to get its input sources - Mail.app stored email it could read, but other things like calendar and chats were inaccessible to it.
(NOTE: the RA code isn't there, I think it was never even useful enough for me to share it)
My favorite use of that was the "ISIM", or emacs-style incremental search in text views. That was nice.
But of course, loading arbitrary external code wasn't sustainable, and that mechanism went away, along with my ISIM.
I no longer track OS X development, so I'm not sure if there's a new equivalent way to do this stuff. It'd be neat to hear.
Always interesting to see some hypertext history. I have a personal connection to KMS, so it was interesting to see that although it wasn't mentioned in the article, it was included in the references - just like in the original WWW proposal. ( https://www.w3.org/History/1989/proposal.html , although maybe the reference was lost in the HTMLization )
KMS was a a multiuser networked read/write hypertext system, a commercial spinoff of a CMU project from the 70's called ZOG.
Excel also has named rows/columns and cells - one of the bunch of useful tips I learned from Joel Spolsky's "You Suck at Excel" presentation - here's the part where he covers that: https://youtu.be/0nbkaYsR94c?t=25m54s
It's about fixing a short in a power transmission line. Sounds simple, right? It involves liquid nitrogen and hundreds of people with possibility of explosions or huge oil spills. That's right, the line is suspended in pressurized oil! It goes on…
I tried to find a good pull quote, and it's basically all mind-blowing pull quotes. But here:
"Every vault also has a nipple which allows sampling of the pipe oil. They said you withdraw the oil through a thick membrane with a syringe (?). This happens monthly on all feeders in the LA area. The samples are analyzed downtown by a staff of chemists who can relate the presence of things like acetylene, butane, and benzene in the oil to arcing, coronas, and so forth. Apparently the oil chemistry is a very good indicator of the health of the segments."
I went to UCSD about 10 years ago, and have lived in the area since.
If we're talking about new faculty, who probably want to buy a house and may want to live near campus, I'd agree that UCSD's location is problematic financially. They seem to be able to attract solid faculty at least in engineering (the people I know), so they must be figuring this out somehow. Certainly some professors are living in small condos who would be living in big houses in the midwest…
However, most grad students while I was there managed well enough. If you don't have kids, and are OK with roommates, you can find places near campus or a short drive away (e.g. Pacific Beach) that are plenty affordable.
I don't really believe that any grad students avoid UCSD because of the cost of living - in a place where you'll only spend a few years and then probably leave.
Those terrible meaningless PDF names, along with wanting to automate grabbing BibTeX from online databases (mostly ACM and IEEE for me), were the main drivers for writing BibDesk, a Mac OS X reference manager: http://bibdesk.sourceforge.net/
I started it back in ~2002 or so, and it's been kept running by a small group of contributors ever since.
Not a multi-user or web-based solution, but it has accumulated quite a few features (including searching many databases) that can make keeping a personal BibTeX file up to date much less of a pain.
Those terrible meaningless PDF names, along with wanting to automate grabbing BibTeX from online databases (mostly ACM and IEEE for me), were the main drivers for writing BibDesk, a Mac OS X reference manager: http://bibdesk.sourceforge.net/
I started it back in ~2002 or so, and it's been kept running by a small group of contributors ever since.
Not a multi-user or web-based solution, but it has accumulated quite a few features (including searching many databases) that can make keeping a personal BibTeX file up to date much less of a pain.
This looks like a nice API on a quick glance.
But, since this service proposes to store email data, I was hoping to find some information on the site about how they plan to make money, and what they'll do with my data when they go away or get acquired.
This reminds me of a talk I heard a long time ago from Takeo Kanade at CMU, who was working on reconstructing 3D scenes from multiple cameras shooting different angles of the same action. One example was basketball, and he had a demo showing a play reconstructed as if the camera was on the ball. Pretty cool stuff. It needed lots of cameras, though, and I remember asking him if they had explored how well you could do with a minimum # of cameras. I remember his reply being essentially that they were less interested in bad results with few cameras :)
I can imagine facilities like hockey rinks buying the cameras and selling the service to the teams that play there, but not at that price. My impression of hockey rinks is that they're not terribly profitable. Most of the ones I've played in seem like borderline charities.
The "ghost" players in these animated replays that show where the system thinks a player should have been are fascinating to see. I wonder how automatic it is - if games could be analyzed like that without much expert input, this would be a really cool thing to have for recreational teams who want to get better but can't afford expert coaching. I'm thinking my late-night adult league hockey team would probably benefit from some replays like this.
> 1. Disable unused components with defconf or make menuconfig.
+1 for avoiding vulnerabilities, but were you saying this lessens the CVE evaluation workload? I'd love to hear about automation for evaluating CVEs based on a kernel config. I've done a fair amount of that manually and I'm not aware of any metadata in the CVE records (or in the CVE json in gregkh's new vulns repo) that includes config metadata.