> If frontier models indeed are a step function in finding vulnerabilities, then they're also a step function in writing safer code. We've been able to write safety critical C code with comprehensive testing for a long time (with SQLite presenting a well known critique of the tradeoffs).
More like: a few people have been able to write C code where the vulnerabilities are obscure enough that we mostly don't discover them very often.
The result of the phenomenon described in the article is that the gap between 99.9% secure and 100% secure just got a whole lot wider. Using herculean amounts of testing and fuzzing to catch most of the holes in a language that lacks secure-by-construction qualities is going to be even less viable going forward.
> I feel like the Japanese found the goose that lays the golden eggs (private trains with real-estate/hotels/supermarkets/shopping-centers). The parts form a virtuous cycle where better trains = more people come to use those other things, and those other things make more people take their trains. As such, the government doesn't have to fund the train systems and so they're not chronically underfunded like they are in so many countries.
The trains in dense cities are well funded. Those in less dense areas have all the same problems as elsewhere in the world - JR Shikoku in particular is withering away. Having your quasi-public railway company engage in aggressive real estate speculation is great when it works (JR Kyushu) but the flipside is what happens when it doesn't (JR Hokkaido) - do you then hang them out to dry?
> And yet, no one will copy them. There's always some excuse. LA is going down the excuse route and adding train lines with no chance of ever supporting themsevles. They are all designed as a handout to the people who are too poor to buy a car, rather than viable alternative to cars, and the fact that they aren't connected to all of those extra things means they'll also never be as compelling to use.
All transport is handouts, only governments can really organise it and no single entity could ever capture all the benefits. The stuff Japan is doing right is mostly not subsidising cars (no publicly funded freeways, no handouts of public street space to people who are too poor to store their car themselves, no tax breaks for employer-provided car parking or company cars), and having sensible by-right zoning laws that make it legal and practical to build dense cities. But even then the various governments of Japan give a bunch of direct and indirect support to railway companies, and outside of the Tokaido corridor they wouldn't be viable without that.
> keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.
How so? When I bisect I want to get down to a small diff, landing on a stretch of several commits (because some didn't build) is still better than landing on a big squashed commit that includes all those changes and more. The absolute worst case when you keep the original history is the same as the default case when you squash.
> Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change.
Do you restrict yourself to 1 non-broken commit per PR? I don't, and nor does anyone I've worked with. If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win. (If you didn't care about that sort of thing you wouldn't be bisecting at all).
> No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
What are you "evaluating"? If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too. Better to have the extra details and not need them than need them and not have them.
> Do you restrict yourself to 1 non-broken commit per PR?
No. To the extent that I can however I do restrict myself to only non-broken commits.
> If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win
It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.
And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
> What are you "evaluating"?
Whether the commit is the one that caused the issue I’m bisecting for.
> If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too.
Neither of these is true. git bisect (run) lands me on a commit, it’s broken, now I need to look whether the commit is broken in a way that is relevant to what I’m seeking.
> Better to have the extra details and not need them than need them and not have them.
Garbage is “extra details” only in the hoarder sense.
> It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.
Skipping a commit that doesn't build is trivial (especially if you're automating your bisects).
> And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that is massive overkill, and the costs outweigh the benefits.
> It took off rapidly but that was hardly because of any hyping and almost entirely due to word of mouth and people actually liking the product, until the press picked up on it.
Not my experience. A whole lot of breathless mentions in media, LinkedIn, and especially top-down company emails. Far fewer cases of people actually liking/using it.
Multiple package managers is fine, what's needed is a common repository standard (or even any repository functionality at all). Look at how it works in Java land, where if you don't want to use Maven you can use Gradle or Bazel or what have you, or if you hate yourself you can use Ant+Ivy, but all of them share the same concept of what a dependency is and can use the same repositories.
Also, having one standard packaging format and registry doesn't preclude having alternatives for special use cases.
There should be a happy path for the majority of C++ use cases so that I can make a package, publish it and consume other people's packages. Anyone who wants to leave that happy path can do so freely at their own risk.
The important thing is to get one system blessed as The C++ Package Format by the standard to avoid xkcd 927 issues.
In the Linux world and even Haiku, there is a standard package dependacy format, so dependencies aren’t really a problem. Even OSX has Homebrew. Windows is the odd man out.
That would actually be pretty cool. Though I think there might have been papers written on this a few years ago. Does anyone know of these or have any updates about them?
CPS[1] is where all the effort is currently going for a C++ packaging standard, CMake shipped it in 4.3 and Meson is working on it. Pkgconf maintainer said they have vague plans to support at some point.
There's no current effort to standardize what a package registry is or how build frontends and backends communicate (a la PEP 517/518), though its a constant topic of discussion.
It might have nothing to do with JR Kyushu but JR West isnt't everything or even the majority of train service in Kyoto. Kyoto has at least 8 train companies, Keihan, Kintetsu, Hankyu, JR West, Keifuku, Eizan, Sagano, and the Kyoto Subway. Japan has over 100. The museum does not appear at a glance to affilated with any particular one - though I only glanced
> what is CI (in practice today, not in theory)? It's just a set of commands that run on a remote machine and then the output of those commands is displayed in the browser and it also influences what other commands may or may not run. What exactly is the big deal here?
The key is hermetically/reproducibly - you don't want to run commands on some random machine, you want to run commands on a well-controlled/versioned machine that won't change under you, that you can recreate at will. Which sure you should be able to do with Nix or something, but the kind of person who doesn't want to use CI doesn't want to use Nix either.
And the other key is whose machine? Particularly when it comes to e.g. Macs, which are expensive. Maybe you have a spare server farm in your closet, but most people don't.
For a solo dev, what are the advantages of _not_ building on your own machine?
Is the compiling and test running too resource intensive?
Do you build every commit? If so, why?
I see the value in larger teams, but for solo stuff I just find it slow and annoying. I'm using go, and it compiles fast, so that could be a part of it.
> For a solo dev, what are the advantages of _not_ building on your own machine?
I end up with all kinds of random crap on my own machine. It's very easy to accidentally e.g. globally install a library that wasn't properly listed in my dependency management. So having a separate standardised/controlled build environment is a good way to catch those. It also helps with flaky tests or random "works on my machine" problems - this way my tests are at least getting run on two quite different machines (different OS/arch/etc.)
Ok, that solves like 20% of the problem. How (and where) are you provisioning these VMs? How are you managing what versions of what are installed on them, and is that process reproducible?
None of this is hard, exactly, but you do have to put in the legwork of doing it, and it's mostly only the big players who've done so.
It's not rocket science. As I said, it's a case of doing the legwork. But you do have to actually do the work rather than just handwave it away. Ok, your VM manager allows you to clone from a disk and maybe allows you to have an overlay layer. Great. Now draw the rest of the owl.
There was a lot of sites that provided some cpanel-like option as long as you're ok with yourcoolname.weirdhostingname.com. I believe they all came with a filebrowser and the always present public_html folder.
There was geocities (now gone) and a couple of *.tk domains that would inject their ads all over your page. Neither makes a great substitute for GitHub pages these days.
I just checked, I’m not using the feature but my current ISP still offers it: https://assistance.free.fr/articles/631 (10 GB FTP storage tied to the ISP-specific e-mail address).
Having looked it up, mine makes it an add-on service for 1,045円/month + 5,500円 set-up fee, at which point you might as well use a dedicated VPS service (which is probably what's actually going on behind the scenes anyway).
More like: a few people have been able to write C code where the vulnerabilities are obscure enough that we mostly don't discover them very often.
The result of the phenomenon described in the article is that the gap between 99.9% secure and 100% secure just got a whole lot wider. Using herculean amounts of testing and fuzzing to catch most of the holes in a language that lacks secure-by-construction qualities is going to be even less viable going forward.
reply