neilv

Nice approach. For some related but different use cases of Debian Live and persistence, I once used a different approach:

Everything in the system and home directory is non-persistent intentionally [1], except for a persistent separate partition that's mounted on directory `~/Saved`.

If you look at the scripts at https://www.neilvandyke.org/lildeb/ , there's complicated wrangling of the partition table, to take advantage of some bootloader conventions for partition ordering&numbering (which, IIRC, kernel hacker HPA told me about), while making the Saved partition's FAT-something filesystem be what's exposed as USB storage when plugged into a Windows box (rather than your Debian Live filesystem)

Regarding persisting additional packages, you could either keep them in `~/Saved` and `dpkg -i` when needed, or (the plan was) you could add them to your fork of LilDeb, and just generate a new image. But looks like I never implemented the part of the updating script that would safely preserve the Saved partition across Debian Live updates. It would be straightforward (IIRC, just copy only the one partition from the new image, and don't overflow).

[1] To try to give a predictable base system each time, despite what messes you might make of it temporarily. Though of course some malware could mutate the "non-persistent" raw storage, in a persistent way, since the USB flash device doesn't provide write-protect.

Ongoing sketchy behavior by NYT's business side seems to be one of the problems eroding the NYT's reputation in recent years.

The publisher may be preserving the family business during difficult times, but... in addition to the money and the upper-crust status that business survival confers, doesn't the publisher and everyone else involved with the NYT want to serve society, and to be known for serving society?

Not to be known for NYT's various sketchy subscription practices?

If I ran a mass surveillance and manipulation company that's not known for great ethics, and I managed to hire tons of people despite that reputation, then probably at least a few of those hires will be unethical/disloyal enough to someday do something against me.

So, whenever one of my employees opts out of surveillance for 30 minutes... is exactly when they secretly get maximum surveillance attention. Because what is that weasel up to.

Humorously, when an employee thinks they are off-the-record is actually when my special security unit is operating off-the-record. With questionable methods. (On-the-record, they spend all their time making employee badges and infosec reminder posters for the kitchenettes.)

> and I think it is somewhat similar to say that you have to "lie a bit on your CV". [...] For context, I'm early in my career (3 YOE)

Please consider this input from my YOE battle scars:

1. Don't contradict your team while in a meeting with outsiders, but then you're obligated to follow up with your team offline, to try to mitigate any damage, and try to make sure it doesn't keep happening. For one example of why, I've seen one person consciously "mis-promise" things to customer, and when I talked with them offline about we couldn't be saying that, because it wasn't true, their response was "they won't remember". Narrator: "They did remember." And that's possibly why that person and a few others aren't very wealthy today.

2. Not everyone believes in "lie a bit on your CV" nor similar dishonesty. You'll probably meet colleagues, who you respect, who react to that with surprise and disappointment. You could also get fired for it, with cause. Especially if you're calling yourself an engineer, since determining and telling the truth is much of your job.

3. Though, on the other side of CV honesty, be careful about always using team-speak/think when in an interview context. Out of habit, you might naturally say "we" when talking about something you were instrumental in. But some people who think lots of people lie on their CV are going to hear that "we" as you generously including yourself in the accomplishments of others. I've started switching modes a little more for interviews, expressly claiming more credit, such as by saying unambiguously when I was the sole designer and implementer of something.

It is happening, within the last two months, by multiple recruiting startup services scraping/monitoring HN, and matching that up somehow with email addresses, in an automated way.

I'm only a few more AI slop HN posts away from quitting HN.

I will only look at AI slop if paid to do so.

(Scouting ahead for alternatives, I wouldn't mind a Lobste.rs invite, to see whether that's pleasantly anti-slop.)

Good catch. I've walked past that many times, including when actively looking for the entrance, and never saw that sign.

Maybe because it's about 4 stories up, almost straight up from the sidewalk, and at a bit of an angle if you're not coming from the bridge, and above something that says it's just advertising the parking garage to cars. Oh, and looks like blocked from sidewalk by trees, if you're coming from the neighborhood rather than the bridge. So maybe visible to passing cars, but not to the generally car-free people in the neighborhood.

(The first couple times of actively looking for the entrance, I walked past it, before doubling back, and finding the white-on-light-pink signage at street level.)

1. Are super-organized, highly-capable, fully-sane terrorists the only threat? Or does the threat model include mentally-ill / personality disorder people, who might make mistakes, or taunt those whose job it is to stop them? Or include people of either kind, who create diversions? Or include people who make a statement in an unexpected way?

2. Did the captain, flight control, and everyone else who needed to decide, have definitive information that the report was only an innocuous Bluetooth advertisement for an innocuous consumer device, and somehow knew that no other threat was going on? If not, then I'd commend whomever decided to follow protocol, and err on the side of inconveniencing a lot of people, rather than risk tragedies that the protocol was designed to prevent.

I once consulted on some aviation-related software (not the safety work prominent on my resume), and a company announcement came through, that you must never use a few specific words commonly heard in software development. The two no-no words I recall were "crash" and "bomb". Don't write them in code or documents, don't say them on the phone or videoconf, etc.

Those terms have senses that people in aviation take extremely seriously, for extremely good reasons. A miscommunication can trigger a lot of life-critical emergency mode sudden effort and stress for people. Effort and stress that is occasionally extremely necessary.

It made sense, once I thought of it.

In this particular case, it sounds like it wasn't the teen's fault, nor even a teen being slightly edgy. Just an innocuous product that broadcast a very unfortunate name over Bluetooth. Not something most people would've predicted would be a problem.

Yet, under the circumstances, with the information available, it also sounds like personnel were correct to follow the processes that were designed to prevent terrible disasters.

Kendall Square, Cambridge, USA (MIT neighborhood) has something like this, but it's not good.

The space was originally a beloved "public roof garden" which I believe was done as a real estate developer concession to the city. The landscaping itself was whatever, but it was a nice escape from the industrial university campus neighborhood. Get away from your university or industry lab, at any time of day or night, and go up above the commotion, to more sunlight or a view of the stars, with a friend.

Then Google wanted to expand their office space. IIUC, there was a very strange city committee approval, without a quorum, by a single person, who stepped down afterwards.

Much of the public roof garden space was taken. And what remains was remodeled into a nano-Googleplex style grounds party deck, outside their windows. And surveillance cameras, and security guards who often make their presence known.

But it's still technically open to the public. (Challenge: From Broadway, try to spot the signage for it, in a great moment of visual design low-contrast white-on-light-pink signage, amidst larger bold high-contrast color decorations. Even if I tell you it's in a recessed corner beside a parking garage, and you have the benefit of StreetView rather than walking along the sidewalk, and I even tell you what color to look for, you'll have trouble. Under normal conditions, you'd have no idea the public access concession was even there, which presumably was the task given to the designer who must hate that this is what their career has come to.)

And when it's not locked, you can go up there, and get a lookout view of some of the city, while being under the evil eye yourself, and constantly feel like you should leave, which you soon do.

> Mostly I just want you to come around on the diagnosis, and agree that we need to fix it properly for the first time in 50 years. [...] At Google, rather than putting a little black desk on every interview loop, they just assumed all the interviewers had their heads up their arses (an evidence-based assumption), [...] People are not allowed to question whether the interview process is valid. Challenging it is akin to casting aspersions on the entire engineering staff. First of all, how dare you?

A scoping/guidance suggestion to start: Is the problem of improving hiring more tractable if you don't try to solve it for Google?

What if Google is hopelessly tainted with biases, from having run almost every single person there through a process that you acknowledge is a horrific load of poo. Which not only means the process has become a religion/frathouse that people are proud to have been accepted into, and will defend fiercely, but also greatly determines the strengths and weaknesses you have to work with, if you want to get them to do anything else.

What if you instead start with smaller companies that don't have the baggage of FAANG, and look at their requirements, which may include some mix of (off the top of my head): prior experience, learns whatever is needed, creative/innovative, works as a team member, aligned with company success, professionalism, good for morale, good for catalyst, will have some loyalty during the harder stretches or when tempted by a little more money.

It would be nice if, instead of many 2-person startups making their first hire with the assumption that they should mimic the known-bad processes of megacorps (often based on their own FAANG-oriented interview prep in college), the megacorps were desperately trying to figure out how to hire as smartly and genuinely as SMBs, but at FAANG scale and with all the FAANG legacy workforce biases clawing them down.

> And then, importantly, each work item also counts once for the candidate: they walk away with a permanent, portable record of what they did and how well they did it, signed by you, whether or not you make an offer.

Why would this be useful signal?

I'll assert that you're in a professional environment of: dishonest posturing and oversized egos in startups, bureaucracy and butt-covering in established companies, and a culture of thin niceness veneer.

I'd think all of that would be barriers to a useful Permanent Record.

> This system is basically worth exactly what your honesty is worth. If you hand out gold stars to everyone, you’re just reinventing LinkedIn endorsements, which are worthless. Companies whose stamps mean anything will be the ones known for only handing them out for quality work. Being a hard, fair judge is an advantage for everyone.

What is the precedent of that working, in the environment I just characterized?

Given our current environment -- which isn't going to change easily; it works for the people who have most of the money now -- seems like a not very reliable new category of surveillance capitalism. But it gets worse... A lot of techbro founders will immediately see this as the next sketchy, hated tech company, which won't only charge companies a fee to participate, but the real business will be twisting it into off-label uses. For example, with whom and when a person has interviewed, and who which companies are interviewing, is valuable data to sell, no matter how useless the feedback. They could also see how close you could get it to a protection racket, by selling Pro individual memberships on the side.

So we get bad signal for the ostensible service, in exchange for additional techbro dystopia.

I think the usual theory is: So many of us got into computers because we loved playing video games, and wanted to make them, and then loved making games. So the game companies that will pay you money to make games (even if there's a lot of non-fun to it) don't have to pay as much as, say, a surveillance capitalism company of sharp-elbowed careerists.

IIUC, the majority of FAANG is people who are there, first and foremost, for the paycheck. (And then maybe they get interested in the work, especially if it seems like progress towards a promotion for more money, or because it gave them skills or resume keywords that they can then use to get more money elsewhere. It's the money/career that's interesting first -- craft and product are only a consequence of wanting the money.)

Great photo up top, of author's family members entering the "America[n]" airliner.

Yeah, and even in good faith, the questions can be problematic.

Example: At the very start of the interview, candidate suddenly feels like they have to hide something about their religion, sexual orientation, or whatever, in how they answer. Or feels like their candid answer to the icebreaker was not received well.

Which is the opposite of what the interviewer intended, with an icebreaker, but their training didn't include how tricky casual icebreakers can be.

Some good points. Just a heads-up about something interesting I heard/read in training...

"Innocuous" icebreaker questions about hobbies, the weekend, or whatever, can be surprisingly problematic.

The questions and answers often inadvertently imply things about family status, religion, physical ability/disability, socioeconomic class, age, heritage, etc. that interviews are supposed to steer clear of.

For me, this was best illustrated by one of the https://www.linkedin.com/in/lornaerickson/ funny video skits, in which the interviewer character was using "innocuous icebreaker" chat aggressively to try to extract information all over the no-no list of things you aren't supposed to ask.

(Then the skit was funny again, after the fact, when I was in an interview with some barely-out-of-school founder, who was intentionally doing one of the things from the skit...)

> Or the “this person knows how to interview” part (which generally, but not always, correlates with experience and emotional maturity).

I think that "generally..." is a little harsh.

The person might just not have worked in a stereotypical corporate drone environment before.

Or they might normally have been able to handle the corporate drone interview theatre, but are overextended by the context (e.g., laid off in this job market, which can easily be more stressful and existential than most actual work situations), and a bad interview hazing just yanks on that.

There's going to be more and more overstressed people showing up to tech job interviews, and people on the other side of the table will need empathy and understanding, if they're going to make good assessments despite the context.

Positive credit is not the only purpose of attribution.

There's also the named authors not taking credit for something they didn't fully do, regardless of whether the credit goes to someone else.

There's also traceability, if the authors/provenance needs to be considered because of some kind of problem or potential problem -- technical, legal, security, or otherwise.

I disagree. Imagine a human co-author on a work. "Written with a co-author" would not be sufficient attribution.

Who is actually writing this very concerning California Internet legislation, which will ultimately affect the entire nation and world?

Did someone write California Internet legislation without consulting any California Internet companies?

Did some California Internet companies write California Internet legislation?

Did some other party write California Internet legislation?

I knew an adolescent kid (not me) who built the robot from that exact robots book. A historical thing to appreciate is that, even though this book was unusually prescriptive and nuts&bolts detailed, for the time, building the robot was much harder, and much less likely, than it would be today, even to the same design.

This was pre-Web, and it involved mail-order adventures, and you were kinda alone.

IIRC, he got the book in the gift shop at the Oregon Museum of Science and Industry, on a school field trip. Just getting access to the initial information was almost random.

Then one of the most obvious components -- the motors with the right gearing and power requirements and weight properties -- weren't at Radio Shack, and not something you were likely to be able to cannibalize from a yard sale.

So first you needed to order a catalog from a company known to sell the motors in single quantities. Then, once it arrived, weeks later (eons in kid perception of time), you needed to convince parents that it's a good idea to write a check or use their credit card, to order these expensive parts from some weird mail-order company they've never heard of. (And probably none of their friends have their kids doing this.)

And there are no forums where you can talk to other people doing this. And no influencer YouTube channels showing other people succeeding at it. All you have is this one book, and dubious parents.

Then you needed a bunch of hobby-shop supplies, like various sheets of balsa wood, rods, etc.

In absence of printable STL files, and cutting patterns, and PCB layouts you can send off, and affiliate links, or parts kits, if you stick with it, you eventually scrap a lot of supplies building the mechanics to something that looks minimally viable.

And you eventually risk plugging in your first soldered circuit board into the family's only home computer (no, you don't have a hobby/educational microcontroller SBC). And if it zaps, you might not have anything to program on for a long time.

If it doesn't zap the family computer, then you try to get the mechanics not to rip themselves apart.

So a kid of that era who embarked on the project might never get a working robot, but they would learn a lot about a breadth of things, in the process of trying.

Congrats on graduating.

Like everyone else at the moment, you're living in interesting times.

AFAIK, there are not enough respectable companies for even the senior engineers.

(And you may have already noticed that a lot of companies are run by people who make a half-hearted effort to drape the company with positive PR language. But they'll soon hint at their true intentions with their actions. Even in a brand new startup, you can simply look at equity allocation, to see what the founder actually thinks about warm-fuzzy ideas like social equality and valuing others: compare their allocation of wannabe-billionaire founder shares, to the token amount of peanuts in stock options that they think the first hires deserve if the company is successful.)

The good news is that a lot of people are looking for high total compensation, or career stability, as higher priorities than respectability, so... less competition for the respectable jobs.

One idea: make a ranking list of companies based on how respectable you think they are (recognizing that most have downsides), and then see how close to the top of the ranking you should focus your energies. Do a first shot at this ranking early on (and revise over time based on actions, not overtures), and you might check yourself when a company with low respectability ranking approaches you.

When you find a good company, let people know.

> Obviously an LLM generated the code, but I felt comfortable following along and understood what it was doing, reading and Trusting the Tests. [...] My difficulty is with thinking the way that lets me write Scheme.

There's your problem, right there. Vibe-coding is sabotaging learning before you even start.

You can learn some things by reading good code, but there's no substitute for the exercise of thinking through problems yourself. (Also, an LLM won't necessarily give you good code.)

First learn paint fence, Daniel-san. Not watch third-hand videos spliced together of other people painting the fence, and thinking you'll understand much of anything about it.

> I have the ALGOL neurotype.

Good news! Scheme started as a block-structured imperative "algorithmic" language in the spirit of ALGOL. Just with more parentheses.

Write as if in ALGOL, but using Scheme's comparable syntax and language features. And lots of parentheses.

Don't get confused by CS professors showing you pure-functional features, the metacircular evaluator, recursive programming, syntax extension and language-oriented programming, etc. You can come back to that.

Just start coding ALGOL-style in Scheme. You'll accomplish something in an hour.

Once you see it's easy, and are comfortable with that part, then the next thing you do, to get more idiomatic is one of the following, then do the other one:

* Try to get more functional, by eliminating some of the mutations of variables in your code. For example, if you're using `set!` a lot, can you eliminate them by, for example, making them arguments in a named-`let` recursion. (Or, instead of named-`let`, spell out the recursive functions, like some intro CS professors will want you to do, but that can obscure things that are obvious once you see the named-`let` lexical structure.)

* Try to get more language-oriented, by making a little domain-specific language, maybe with `syntax-rules`, `syntax-case`, or `syntax-parse`.

One more tip, for anyone coming from C, C++, Rust, etc., who may like trying to know the cost of everything: If you get hung up on high-level language features like GC, and not knowing which of a number of ways of doing something, is the right (performant) way, try not to. But if you want an intuition (that might be a lie), imagine that needless mutations or allocations may be more expensive than finding a different way to do it. And each FFI call has very expensive overhead. At one point that I had to make highly performant code, I made a little tool, to help confirm my intuitions: https://www.neilvandyke.org/racket/shootout/ There's also a statistical profiler in Racket now, and you can even (with work) rig it up in production systems, for measuring real-world workloads, which I used to guide optimizing performance of a large and complicated system.

Like you, I've found that working with people of integrity (or some qualities closely related to that) is very important to me.

Not in a "new-grad or corporate PR appropriating meaningless platitudes" kind of way. But in a "I have seen multiple times how one untrustworthy person can easily wreck all the work of a team or organization, and make their lives miserable, so averting that is a high priority" kind of way.

Lately, in business context, I tend to characterize what I seek from people as "alignment". I think that many (not all) business people are still willing to buy in on that.

And it will just have to be a given that the company and team goals with which people are aligned are respectable.

What seems to be getting more difficult in the last few years is finding companies with respectable goals. Of course you knew to avoid any company in crypto. But now, with with a new VC gold rush of AI (often involving the same people who were happy to run crypto scams), there aren't a lot of startups that look respectable.

Not all AI companies, nor all companies doing AI, are bad. But how do you find a respectable one, in a gold rush?

OTOH, this phase will tell you who cares about doing great work, and who is inclined to just fling around slop.

> Highlighted Answers: When people are researching, they want helpful suggestions. Now, when AI Mode provides a list of recommendations — like the best language apps for an upcoming trip — highly relevant, high-quality ads are eligible to appear on that list as a Highlighted Answer.

The user asked for the "best language apps for an upcoming trip"?

Are you going to answer their question objectively?

What if the correct answer is apps A and B are what they need, yet the publisher of app C paid you to be a Highlighted Answer?

What if C is not only not among the best, but is a toxic load of poo?

Also, when are you going to stop often blatantly plagiarizing things people wrote on the Internet, for your "AI" answer, even though you absolutely know you're violating the social contract that built your company, and destroying the creators from whom you're stealing?

Great question, in light of vibe coding.

Yes, and no.

I absolutely still believe in small teams of highly-effective and aligned people. And they should be working smarter, and thinking forward and more holistically, than anything LLM-ish based generation and reasoning can do.

Let's say, 5 years ago, you already had vibe coding. It wasn't implemented atop LLMs, but by VCs giving you full-time use of a thousand junior software engineers and product designers, from a country of very energetic and educated people, but with much lower cost of living.

(Not offshoring in general, but a particular thousand-juniors kind, for the analogy.)

Your team of founders spends all their time prompting the thousand-juniors to do things. The thousand-juniors work very rapidly, but they only do what you tell them to do. And they tend to copy heavily, but with a little obfuscation. They don't think holistically. They always speak confidently, regardless of how little they understand. Because of how they were taught to knock off tasks, they never have an original thought, or don't voice or act on it if they did. They're just trying to knock off sprint tasks by technically doing what you told them. There is also a lot of bloat like a thousand juniors pasting together 'solutions' they looked up on Stackoverflow, which make little sense (e.g., pulled in a whole new framework to do one thing, rather than do it with the existing framework). This is how they were trained.

With your founding team trying to herd this thousand-juniors army of Jira ticket closers, they will churn huge amounts of code, and the appearance of functionality, very rapidly. No one will have occasion for much insight into anything.

That just might work, if it was ZIRP, and you are just putting up a Potemkin Village to get enterprise sales and more investment, until an exit. But is a terrible way to get PMF, innovation, or anything sustainable.

That said...

One way that this vibe coding competes with, say, a stereotypical "10x" Lisp hacker, is when you're a "business" cofounder, and you talk over a new idea with the hacker cofounder, who then worked through it all weekend, and shows you a PoC on Monday. You don't understand the subtleties of what the hacker did, but you're impressed that they could deliver "functionality" so quickly.

But today, your thousand-juniors can also deliver this "functionality" over the weekend. You can't (initially) tell that they just mechanically interpreted the task they were given, without original thought. And they maybe they even started by cloning and obfuscating two similar-sounding bases of GPL code.

But to you, the business person, the effect looks the same as the hacker who thought about it and used skill. And you might not be able to tell, for months, that the thousand-juniors collective result just isn't very bright, nor sustainable. (Not to mention that sometimes they veer a little too close to plagiarism or IP theft in how they work, and you don't know when you're gambling on whether they'll/you'll be caught.)

But the existence of this thousand-juniors rapid turnaround of "functionality", and you not being able to tell the difference between smart product engineering and slop, means that you never even try to build a more effective team, nor go through the experiences that help you become one.

I contributed to a contemporaneous large and complex system in Lisp (Scheme) that used most of those.

It was one of those things where 1-3 programmers, working with the right tools and thinking, could out-perform all competitors, no matter how much resources competitors threw at the problems. (I can't take credit for the initial architecture and implementation: that was all someone else.)

The system actually outlived Viaweb by decades, and I suspect still uses Scheme for a lot, especially for the necessarily complex backend.

(Half the problem for Scheme uptake was that most students only saw it school, as presented by a CS professor in an intro class, and then they did annoying homework, so they hoped never to use it again. They should've seen what we did with it, making it fly in ways that a CS professor wouldn't in first-year classes, compared to how it would've been done in other languages at the time.)

> One way we used macros was to generate Html. There is a very natural fit between macros and Html, because Html is a prefix notation like Lisp, and Html is recursive like Lisp. So we had macro calls within macro calls, generating the most complicated Html, and it was all still very manageable.

We just used lists and functions for HTML. And often with quasiquote, when we wanted to splice "dynamic" bits into a substantial chunk of "static".

I didn't try to use macros for HTML until a decade after this talk. I liked the simple DSL, and leaning on buffered I/O ports and string ports, but nobody else seemed to like it as much as I did (maybe because they didn't have a prolific colleague doing 10x code-writing in a rather more delicate way of generating HTML):

https://www.neilvandyke.org/racket/html-template/

(Don't look at the code, though. I wrote it before Racket got submodules, which are great if you have a strict, non-CL-ish module system and syntax extension mechanism that otherwise make some things much harder than in CL. I have a TODO note in there to refactor it with submodules, but I had to redirect my time towards other languages, for reasons having nothing to do with language merit.)

I remember your great work on pie menus, from when I got into HCI. And that's quite a cast of stars on that paper!

Before I went to MIT as a student (almost the same time as Ted Selker arrived as a new professor/researcher), Mark Weiser offered me a job at PARC (new project he was doing on ubiquitous computing, which I really should've joined).