> Incremental compilation is not cleaned up. Older deps pile up and don’t get cleaned.
This is one of those problems that’s both huge/important, and probably impossible to solve. It bites me all the time, I have a measly 1TB nvme disk and I basically have to wipe my target directory and docker build cache (I have a shared cargo cache volume across builds) every other day. I’ve had this workstation for 2.5 years now and I’m honestly worried about nand endurance coming to bite me soon.
How would one even solve this? When do you know a cache entry won’t be used any more? Trace back provenance of artifacts to their sources, and if the mtimes have been bumped just delete the artifacts? It’s not like resetting source files to older mtimes is a good idea anyway…
I disagree it’s impossible to solve. Huge C++ projects don’t have continuously growing build directories and can still compile incrementally correctly.
That’s because they overwrite the old artifacts with new ones every time, which has its own problems: you could end up reusing stale artifacts if your compiler version changes, or if different compiler args are used for the same artifact, and a bunch of other stuff. Rust computes a digest of all the relevant build environment settings that may need a different artifact to be built, and uses that digest in the file name. That means you basically never have issues like “oh crap the incremental build broke, do a clean build instead”. (Amongst a whole lot of other benefits I’m sure.)
But this technique errs on the side of not using invalid artifacts, at the cost of not having a good system for expiring them. To maintain the goal of never having to worry about when to require a clean rebuild, solving cleaning of stale artifacts becomes a much harder problem.
No comment about the substance of the article but I just have to give props: this site loaded incredibly quickly for me. Like it felt like a handful of milliseconds between tapping the link on my phone and it showing up, already scrolled to the right anchor within the article. Bravo on making it snappy.
Indeed - a nice bloat-free site, but it still looks reasonably modern.
I needed the SMBus specification a week or two back, and was greatly amused by the 1990s-looking website which hosts it - still with purple bevelled buttons adorned with Comic Sans text! But it's crawlable, archivable, won't break when some framework or plugin gets automatically upgraded, and will hopefully still be there in another decade.
Yeah and fuck them, right? Won't these parasite breeders learn that they have no right to take vacations? They should experience nothing but misery until their children are 5.
Unrelated, why are so few people opting to have kids?
Eh… as someone who agrees, I think overlapping windows are a feature, not a bug. Very often a window is transient, in that it’s something I need to give my attention to and once it’s done, it’s gone. In a naive tiling window manager, all windows have to re-tile themselves while the transient window is open, just to then return to their previous layout once it’s done anyway. The ideal interaction in my opinion is for the transient window to simply be “on top really quick” and I can just alt+tab if I need to see what’s underneath it. The degenerate case tiling proponents always point out is that “what if the window you need is obscured” and tbh I just never have that problem? Between a quick alt+tab, or the win+arrow shortcuts doing “tiling-lite” when I need it, I’ve never thought “gee I wish something would figure out a tile layout for all these windows”.
More generally, tiling is what you want when you have a particular layout you like, each window has a reason for existence, and you want them all open and visible at the same time. That constitutes like, 10% of my time using a computer. Mostly I just want “give me a new window, let me do a thing, then it’s gone”, with said new window occupying 100% of my attention while it’s there. Having to carve out space for it in a tile layout (even if the tiling is automatic) just doesn’t make sense with the way I use my machine.
A tiling window manager is a lot more useful if it doesn’t always tile, yes. The ones I’ve tried don’t seem to have a graceful way of saying “allow overlapping just this once”, but I’ve only tried a few of them (i3 is the one I remember most. I honestly can’t remember if I tried hyprland. If I did it was probably only for a few minutes.)
Now, you seem to be upset that I don’t “have a point worth trying to understand”, perhaps you can enlighten the class and explain why your tiling window manager of choice does this better? I’ve already described my ideal interaction, so if your WM does this well I’d love to hear about it. As it is right now, you seem to be the one who’s withholding details.
> But Linux took over the world and it had a crappy UI. I was there, back when Xorg didn't even exist, running X and messing with modelines on Linux. All the window manager sucked big times.
My first exposure to Solaris was in 2003 when Linux had Gnome 2.6 and Solaris had CDE. The UI on my Debian box seemed decades ahead of the Solaris machines I managed, which looked like Windows 3.1 and performed about as well.
Combined with Linux package managers being infinitely better, the GNU core utilities having so many more conveniences and options than the Solaris equivalents, I felt like Sun was this dinosaur that couldn’t die fast enough. I’ll still never understand why so many people praise Sun for its engineering culture when free software seemed so superior to me at the time.
My favorite anecdote exemplifying my opinion about Solaris at the time: you log into the console of your Sun workstation, running SunOS, with your Sun keyboard plugged in, and press backspace. It echoes ^H back to you. They couldn’t even figure out how to configure their own keyboards correctly out of the box.
Maybe in the 90s the standards were different. Maybe their tech was better. But by the time I ever used their software is was the butt of jokes.
> My favorite anecdote exemplifying my opinion about Solaris at the time: you log into the console of your Sun workstation, running SunOS, with your Sun keyboard plugged in, and press backspace. It echoes ^H back to you. They couldn’t even figure out how to configure their own keyboards correctly out of the box.
That's really an old-school UNIX convention that should have died with the move from teletypes to CRT terminals. The default behavior was that ERASE was # and KILL was @ (rather than backspace and Ctrl-C). It was typical for these to get set properly on logging in.
Well, of course, getty doesn't know whether the thing plugged into the serial port is a teletype or a CRT terminal. But the actual Sun console isn't a serial port!
KILL isn't Ctrl-C. That's INTR, as you can verify in stty -a. KILL is Ctrl-U.
> My first exposure to Solaris was in 2003 when Linux had Gnome 2.6 and Solaris had CDE. The UI on my Debian box seemed decades ahead of the Solaris machines I managed, which looked like Windows 3.1 and performed about as well.
Linux having better UI than proprietary Unices (except SGI) was true from the beginning. In 01993, even before package managers, the Linux standard was color rxvt, color ls, Seyon, fvwm with multiple virtual desktops (really important at 800×600), Emacs preinstalled, and you could termify your web browser and whatnot so you could run them at home on a dialup shell account. Proprietary Unices (except SGI) had monochrome xterm, vi (with no arrow key support), and typically either twm or mwm, which both looked like shit and still do. Suns sometimes had olwm but Sun had sort of abandoned Open Look by that point. If you had a Sun at home connected through a dialup shell account, you could forget about running any TCP/IP apps on your Sun. By 01996 the Linux world had slirp, so you didn't even have to termify your TCP/IP apps, while Solaris didn't even include a C compiler anymore.
CDE seems like somebody thought that the problem with Motif was that, although it was butt-ugly, it wasn't quite ugly enough.
And, yeah, backspace worked. Also automatic window resizing. And for years Solaris had a totally fatal TCP round-trip estimation bug which made TCP connections to Solaris machines over dialup incredibly slow. Linux was just dramatically more technically competent.
Sun did have a pretty amazing engineering culture. They shipped SPARC, Open Look, NeWS, Java, HotJava, HotSpot, NFS, Sun RPC, yp/NIS, Spring, ZFS, OpenBoot/Open Firmware, and I think even Sprite, and for a while they employed the Tcl team, bringing Tcl out of the stone age. But they sucked at fixing the fatal flaws in their actual products, and half the engineering achievements in my list above were murdered by Sun's incompetent management.
This was my experience as well, from the same time period 2003ish. My University's computer lab was all Sun. I thought CDE was shocking, I was immediately repelled by it when I started using it and had a similar experience with those Sun keyboards.
One of the other students in that class gave me a Mandrake Linux cd (It ran KDE) he taught me how to use SSH. After that I worked from home and submitted my assignments remotely. I have not looked back from Linux since.
I don't think it was limited to Sun. The first job I had out of university there were computers running HPUX also had CDE gave me flashbacks straight back to university. It definitely gave me the impression that all the commercial Unix companies were ancient Dinosaurs that had zero taste.
Ahh, ^H brings back memories. We had Solaris x86 machines in the computer lab at UC Santa Barbara when I was there from 97 to 02. They were deathly slow never mind that CDE was miserable too. I made it slightly less painful by loading the BSD versions of the utilities and using those. Pretty much gave up and ran FreeBSD on the desktop with Window Maker.
Sun got by because they had faster and more reliable hardware than what was available in the x86 space at the time. eBay's services ran on a handful of 64 CPU Starfire servers. And proprietary UNIX workstations had a bunch of specialized apps that weren't available on Linux at that point.
If the pedestrian hasn't gotten to the driveway quite yet, and you're stopping to let them get there and cross out of an abundance of caution, then it may not have been legally required for you to yield. And the motorcyclist behind you could very reasonably have seen the pedestrian too (and reasoned that the pedestrian was still several seconds away from getting to the driveway) and not expected you to stop. In such a situation, such an abundance of caution could have easily "caused" an accident, in that not yielding and proceeding through would have been perfectly safe.
(I'm of course being steel-manning GP's argument here, it could have very easily been that the pedestrian was already crossing the driveway at that point, I didn't see the video. Point is, "more caution" doesn't always mean "less chance of an accident".)
> Point is, "more caution" doesn't always mean "less chance of an accident"
that's a fair point. For example, if you're on a highway and traffic is moving at 80mph however the speed limit is 55mph and so you're driving 55 you're doing way more harm than good. Becoming an obstacle to traffic makes an accident more likely regardless of whether you're right or wrong.
Having said that, I do not see the waymo at fault here at all. The other car driver turned a minor accident into a fatality without involving the waymo, pedestrian, or even the motorcyclist. They were just not paying attention and ran over the poor person.
The answer to this is gonna vary wildly depending on what kind of codebase it is.
A large, mature codebase that predates LLM’s and for which changes need a high level of scrutiny regardless of who made them (think llvm, WebKit, important foundational software), you’re going to want humans in the loop as much as ever… I think reviewing LLM output is the most important thing a human can provide.
But for vibe coded apps where you can just one-shot another one if anything goes wrong? Just vibe the reviews too, who cares. Let the robots review the robots.
Be careful with doing AI review if your codebase is in the former category. Or your codebase will quickly turn into the latter. Complete with “you can just one-shot another one”, because if nobody understands the code any more, there’s not much lost by just you (or your competitors, etc) replacing it wholesale with an AI-written alternative.
I struggle with this a lot. 2 years ago we had a half dozen PR’s a day with a lot of careful review, and now there’s more like 30 of them per day and most people are just rubber stamping them after the AI reviews it. I’m still fighting the good fight trying to review every line of the PR’s I have time to look at, but that constitutes maybe 10% of them. Not only am I barely making a dent, but it’s awkward when I post nitpicks like “this function should go in this module”, etc, the author usually looks at me funny like “why are you even reading this”. Our codebase is gradually becoming more and more vibe coded, and it’s depressing me.
Not really interested in getting into a debate here, I’m just pointing out that GGP said “openness and also the scale”, to which you ignored the “scale” part and pretended it’s only about being corrupt in the open versus in private. I can point this out without making a comment at all (although I have my opinions) on whether I agree if the scale has changed.
(To be clear, I absolutely believe the scale has increased tremendously, but arguing about this is gonna be fruitless because it’s all subjective, there’s no hard numbers for any of it, and anything I can point out, you can just say “well that’s because they’re doing it in the open now, they were always doing it”, which is just as unfalsifiable. There’s basically no good outcome to debating this.)
> arguing about this is gonna be fruitless because it’s all subjective, there’s no hard numbers for any of it
I was just genuinely curious what somebody with your set of opinions has in mind for a time frame, because "1/100th the corruption" is too vague for me to quantify in my head.
As for arguing, I generally don't expect to change opinions with comments, especially those of whom I'm engaging with directly, so no worries there.
1/100th is hyperbole. But it has gone up. My opinion on the timeframe is the obvious one:
Since Trump. Entirely.
I generally think there’s actually not that much corruption in politics in the US. Mostly just insider trading, if you count by dollar amount. But I think generally there have been studies on the net worth of people before they are elected to public office versus after, and it’s within a few percentage points of the general population. There’s also the issue of lobbying firms hiring ex politicians but to be honest there’s something to be said for an ex-politician as a lobbyist: they have expertise and connections, they’re valuable to lobbying firms even if there’s no favors involved.
What we have now is:
- The president openly hocking a cryptocurrency and making billions off of it
- Taking money for early access to his posts on truth social, which is essentially how he communicates to the public. “Give me money and I’ll tell you first”
- Giving pardons to his supporters in a brazen and obvious way
- Taking donations from private donors to fund his pet projects like the White House ballroom
I could go on but like I said, I’m not really interested in the actual debate here because nobody’s gonna change their minds if they haven’t already.
But the previous administration denying a fair primary process gave us the present one due to forcing an unpopular candidate. They collude with each other so much that they're effectively one party.
When google trained a neural net on Go moves, using some text notation for them, with no other vocabulary of any kind, just predict the next go move, they noticed a representation of a Go board had essentially formed in the network, all on its own. It had never “seen” a go board, or had one explained, but they could map neuron states to go board squares pretty much 1:1.
I truly think that LLM’s with hundreds of billions of parameters in their neural networks have all kinds of hidden “models” of things that arise from the simple act of predicting tokens. We’ve seen that the hidden layers in their networks model all sorts of program execution state for instance, when they’re working on coding tasks.
“Predict the next token” is a way of shaping/reshaping the neural network until it actually develops models of the things you’re giving it. Like the go board example. And I would wager that it has a compounding effect: once you have some useful models in the network, they can unlock the creation of other models, and so on.
> It had never “seen” a go board, or had one explained
I assume that you are referring to AlphaGo or AlphaZero. In either case, this statement is not correct. Both algorithms most certainly know exactly what a go board looks like, and what the rules are.
In the case of AlphaZero, it initially did not know how to best play the game, or what strategy or tactics would work. But the connections between the neural network and the go board are hardcoded, by humans.
reply