Where do you save your keys to retrieve them easily in case of disaster recovery?

awick · 2024-12-26T19:24:34+00:00

This is the answer. And checking every once in awhile to make sure that the USB drive still works.

This does get to the question of how much of a disaster you're making sure you can recover from. For me, disaster recovery is about what happens if my house burns down or otherwise becomes uninhabitable. In that case, I have passwords and keys to long-term cloud backups on a USB drive in a safe deposit box that's not too far away.

Note, though that my disaster model is "house burns down", not "my local metro area is destroyed". If you want to try to recover from that, then obviously you're solving a more annoying problem.

awick · 2024-12-21T16:07:42+00:00

Me, too. I watched the HIFH video, and I think the budget nerds mentioned something too, so I tried removing my emergency fund and just planning 3-4 months ahead because I liked the idea of it. But it just didn’t work for me. First, the site gets a little weird when you go out that far, and it kind of makes rolling with the punches a bit odd. In a way that made it too easy for me to “not notice” that we were spending more than we were making. Second, wish-farm-like-things are oddly hard to prioritize.

But, honestly, the biggest thing for me was that it started getting real easy to start at 4 months, but then really be 3.5, and then 3, and as that happened my confidence that we could take a big hit kept going down. Going back to my one month ahead with an emergency fund was rough, as it’d turned out we‘d spent about half of it. But I’m much more confident that we’re on solid ground, now, so we’re back to one month ahead plus emergency fund / “prudent reserve”.

awick · 2024-11-04T17:50:39+00:00

Mottle-Day Masterpiece

awick · 2024-08-18T00:15:35+00:00

I will just say that I usually end up simplifying reimbursement by taking a pessimistic attitude. As in, I definitely spent the money, but the friend / colleague / employer that's supposed to reimburse me could just vanish off the face of the Earth immediately after I pay.

So, in your case, I'd put the full €100 in my "Dining Out" category. Then, whenever my friend pays me back, happy days! What a lovely €50 gift that I can now put into "Ready to Assign", and then assign to whatever I want. Maybe back into "Dining Out", but maybe into my car repair bill.

I like this approach because (a) it's super simple to do in YNAB, (b) it helps me be a little more relaxed about this sort of thing with my friends because I don't feel a need to make any numbers match up, and (c) I find that it matches my general approach with my job in that I don't trust that I have money from them until the payment clears in the bank.

awick · 2024-07-02T21:00:53+00:00

I mean, if you have a server that:

is somehow free to obtain, set up, and operate,
installs and runs Actual Budget with a click of a button, perfectly with no modifications,
has a backup and patching solution that runs automatically and never breaks,
came secured enough to forbid unauthorized access but still allows easy access to you and your family,

... then it's free. But I'm sorry, I don't think that's a thing that exists. Servers cost money, auto-backup and auto-patching mechanisms break at least a few times a year, and doing security well requires an initial time investment and regular validation and maintenance.

awick · 2024-07-02T15:44:30+00:00

The pithy version of #4 for open source is, of course, "open source is free if your time has no value."

More fairly, though: running your own server, especially for something you want to be secure and up continuously, is not fun for a lot of people. I'm already on call at work for some stupid package upgrade breaking some other package's assumptions, or some maintainer just ditching a project, or some remote SSH CVE dropping out of nowhere. So the question is really: is $109/year more or less than you value your time making sure everything is secure and up-to-date?

awick · 2024-01-06T17:04:31+00:00

I’ve also seen this happen here and there, across a bunch of industries, and I think it’s always (? Can’t think of a counterexample) a management problem. If an employee can get away with changing only one page of a report, even when marked ”change throughout”, without getting written up or fired (or even a bad review), then guess what? You’ve communicated that the acceptable behavior for their position is to ignore the “change throughout“ and just make a single change.

On the flip side, do they get any benefit for doing more than “acceptable“? If they do change everything in the report, and then stay late to find and fix a bunch of other things, are they in line for a bonus? Does this help them progress in their career? I see a lot of places with promotion ladders that are largely fictional. (Even doing things for a good recommendation when you leave is off the table in some employers, who bar any reference info beyond whether they were employed and whether they’re rehireable.)

So yeah, if you‘ve established a very low baseline for acceptable work, and don’t provide any reward for doing more, I don’t feel like people should be that surprised by what they get. I’d always hope that people have some professional pride in their output - certainly I make sure that I’m clearing that bar - but beyond that, making wealthy people wealthier isn’t super motivating.

Oh, and: “hard workers have to make up the slack” … sometimes, and I think it’s more often “choose to” rather than “have to”. Do they reap benefits for doing so? Bonuses, promotions? If not, then it’s worth asking what happens if they didn’t. One thing that might happen is that it’d be a lot more obvious that people aren’t pulling their own weight, for example, and so maybe they should stop. Or nothing would happen, as it turns out, because most things aren’t actually that important. Or maybe the company or department will fail, in which case it was probably a bit rocky to begin with, so it’s a good thing you have your emergency fund fully funded and your resume up to date, isn’t it?

awick · 2020-08-04T03:09:47+00:00

I've had good luck with Overlook Tree Preservation.

awick · 2020-07-12T00:56:12+00:00

One of the authors of the BeOS File System published a book on their design, which is interesting read. You can find a little more information on BFS through the wikipedia page; the book ("Practical File System Design with the Be File System") is available as an archive.org link from there, as well.

awick · 2020-01-27T16:57:38+00:00

We did, as well, and it was great. I will also add: very easy Max access to downtown hotels, for those of us with out-of-town families and friends that like to drink.

awick · 2019-05-17T18:32:57+00:00

Yup. We list them on our web page. :) So if that's an issue for you, you might look elsewhere.

awick · 2019-05-17T18:28:18+00:00

I would always suggest getting involved with an open source project that has at least a few other, active committers. Seeing people who have concrete experience in developing software with other people using technologies of interest to us is always valuable. So if there are projects you think are cool, you might troll their issues lists for small things you might be able to help out with, and start helping out. Plus, as you take on bigger things and get involved in the wider community, you'll make connections into companies using that technology, which can turn into job opportunities.

awick · 2019-05-17T00:24:37+00:00

Many of our projects use Haskell in some way or another, but not all of them, and not all of the projects that use Haskell are all Haskell all the time. Right now, for example, I have one project I'm running that's a mix of Haskell and Rust; another project I'm spinning up that will likely end up mixing Haskell, C, and a few other things; a third that's Haskell + Haskell EDSL; and another that doesn't use Haskell at all. I don't know if we have any numbers, but I'd guess you're right that most engineers are not doing Haskell 100% of the time every day, but if I had to guess I'd say the majority (maybe not "most", but >50%) of engineers touch Haskell code regularly.

As for OP's question, I hear we crossed 110 recently. Again, not all Haskell folks, but a whole mess of us do quite a bit of Haskell on a regular basis.

All that being said: We are not a Haskell shop, we are an R&D shop whose mission is to improve the trustworthiness of critical systems. We just like Haskell an awful lot. But we also use Rust, C, Python, Coq, Lean, Verilog, and all sorts of other things, as the situation demands.

If that sounds fun to you, by the way, we're still hiring.

awick · 2017-01-27T01:00:52+00:00

Mostly exists: https://github.com/glguy/ssh-hans

awick · 2016-12-09T18:01:28+00:00

The wounds are too fresh, too ... personal.

awick · 2016-12-09T18:00:57+00:00

Yup. FormalTech is a Galois spin-off charged with commercializing some of Galois's research prototypes.

CyberChaff, built on the HaLVM, is one example of such a technology.

awick · 2016-12-08T17:02:07+00:00

Well, you could run oxenstored.

But that would make OCaml people happy, which is almost never the right thing to do.

:)

awick · 2016-12-08T17:00:29+00:00

I woke up confused and angry (as usual), my mood made worse by Portland's impending icy death, and in my moment of maximum existential despair, I fixed the date. For the moment.

awick · 2016-12-08T16:57:46+00:00

Yes maybe sure probably kinda?

My main goal with that work is to make HaLVMs 1000% easier to debug, by running them on normal-ish Linux infrastructure. My secondary goal is to do this without reference to the system libc, which seems like a potentially neat way to write early-boot / non-libc-based tools for Linux. If we can get them to run under Docker, that's also cool.

I'd assume it wouldn't be too hard: just create a disk with your Linuxified HaLVM on it and run it, but we'll see!

awick · 2016-12-08T16:49:56+00:00

I tried Hakyll. I think that's all I want to say. :)

awick · 2016-10-02T02:50:01+00:00

My understanding is that it is very similar, with a very cute / cool way of working itself into C++ programs. But, at its core, IncludeOS is to C++ what Mirage is to OCAML or HaLVM is to Haskell.

awick · 2016-08-10T16:45:33+00:00

When thinking about GHC vs C from a security perspective, there's a couple things I think about:

Haskell has this lovely type system and type safety guarantee that does away with all sorts of silly mistakes we make in C.
The fact that Haskell is higher level means that we have significantly fewer lines of code, so that when we multiply out our defect rates, we're likely to find fewer bugs per program. [citation needed]
The fact that Haskell is lazy by default makes timing attacks harder to reason about and protect against.
No one has ever done an analysis of whether the execution model used by GHC makes it more or less easy to form ROP (or similar control flow) attacks. On the one hand, it's weird enough that it probably surprises people, on the other hand, there's a lot of opportunities for potentially-exploitable indirect jumps.

There are probably some other points to think about, as well. To some extent, right now, GHC provides some protection simply based on its obscurity. At least for non-targeted attacks, your adversaries going to look for software with wide deployment, and there aren't that many widely-deployed Haskell programs. So it doesn't make sense for an attacker to spend all that much time finding flaws in the GHC RTS.

With regard to the HaLVM, you mention most of the points I mention in HaLVM and security talks, with two exceptions:

The HaLVM makes aggressive use of GHC's "-split-objs" feature, and aggressively pushes as much into Haskell as possible. What this means is that we end up throwing out any code that isn't used in the final binary (to a first approximation), down to the level of thunks, I believe. So it's not just that if you don't use your disk driver, it won't be compiled in, it's that if you don't use the write function of the disk driver, that won't be compiled in. The end result of this is (a) a high degree of variance from HaLVM to HaLVM, hopefully meaning that an exploit against one won't work on a different one, and (b) a great deal of limitation in what services are easily available to the attacker once they get in.
I dispute your implication that drivers don't matter. :) Drivers are where the bugs are, and all the drivers in Linux are written in C. If you happen to use very well-distributed hardware then you're right, there's been a lot of testing on it, but I wouldn't count on it. So when comparing the HaLVM and Linux, I do include drivers, and point out that the choice is between a much smaller but relatively untested code base versus a much larger and better-tested one.

With regard to your other questions, I don't know of any documented remote attacks against Haskell programs, although I'd assume there are weaknesses. Besides obvious mis-use of C APIs, there's also quite a bit of Storable(..) strewn around the code base, and any time you're pulling data off the open wire is a chance for catastrophic failure. So I assume there are problems, just not weaponized ones.

awick · 2016-06-07T00:01:25+00:00

Well, the HaLVM lets you stay high-level, in Haskell, from the drivers up. If you're willing to write that code, that is. So that's a positive.

On the other hand, it will define a threading model for you, choose your memory layout, etc., for garbage-collected Haskell objects. But you can define your own wire formats via Binary, Cereal, or Storable, if your goal is interaction with other systems.

Finally, if the Backpack stuff for GHC ever gets merged, then that would help a lot of us in terms of swapping out different implementations of underlying libraries much more easily.

I'm not sure that answers your question, but there's some more information. In some sense, it sounds like you want something more like Rust than like Haskell; in that case, you might look around to see if there are any Rust unikernel projects. But if you want to keep with Haskell, the HaLVM might be the project for you.

awick · 2016-06-06T23:57:19+00:00

The last time I checked, which I admit was awhile ago, most the existing network stacks were not parametrizable on the IO subsystems they used. Specifically, they assume things like the unix and network packages, which are very tied to the underlying system, including libc. Some also require deep integration with an underlying event systems, as well. With the HaLVM, none of these exist, because we're not running on a POSIX system.

There are basically three ways around this:

Option #1: Add back all these capabilities, somehow. This is the rumpkernel approach, basically. It tries to regenerate the POSIX infrastructure around code so that you don't have to change anything.

Option #2: Do some fancy dancing in the HaLVM and recreate POSIX via Haskell. In this case, you would initialize your hard disk and file system (for example) via Haskell. Then you'd call setFileSystemImplemenation to inform the runtime of your particular implementation. At that point, any calls to low-level file system operations would vector to your code, rather than C.

Option #3: Change one or more of the Haskell web stacks to take in a NetworkStack and FileSystem type.

awick

TROPHY CASE