a-dub

it's actually very stable on x86_64 these days, even with optimus.

The takeaway might be that historic data of market data might often be enough to make a reasonable prediction. Only external data that nobody else has (used) can make your prediction better then the market.

that's basically the definition of an efficient market. demand forecasting and insuring against price shifts is the actually useful thing that the commodities futures markets do.

also a fundamental difference from other time series prediction problems. there are all sorts of weird dynamics that go on before one biosignal effects another, or one metric predicts a failure, where a reasonably efficient market price reacts quickly to well known exogenous factors.

something like that would be interesting. i just get the sense that doing it metadata blind would result in something that learns a somewhat brittle short-time covariance-like structure that doesn't use all available information to achieve best possible generalization and that in the end the benchmark numbers start to reflect some luck with that for predicting non-stationary behavior combined with a lot coming from a pretty good synthesizer that matches previous patterns.

that being the case, it seems the next jump in performance would come from incorporating both metadata and metadata enriched causality and maybe that next jump in performance would be the most interesting jump from a practical system that is useful perspective. (it's more valuable for a system to predict outlier events than it is for it to do an excellent job at synthesizing ordinary behavior)

i think i remember seeing an unlockable bootloader on the remarkable?

Given the lack of forecasting signal, the obvious next step then is to seek out external (exogenous) features in the real world that can help prediction models.

this seems right to me. maybe another interesting approach would be a fusion llm+ts model that does multiple-input-single-output with input metadata and causality narrative. so it "thinks" about what data it has and how predictive it may be of the target variable and when something "interesting" occurs it uses the big priors to synthesize a good guess at what it would look like.

so you'd have something like the time series data plus textual narratives of the causality stories as the training data.

woah! there's a whole genre of old, abandoned and dilapidated bowling alley pics on the internet and it's amazing. thank you for that!

and yes, you should post pics and stories like when jwz renovated the dna lounge. (i think one of his first posts was about building his own pos system, fwiw)

If you are using Perforce as an enterprise system, $500 is peanuts. Perforce can get pricey.

i think it was $600/seat back when i paid attention (20+ years ago). don't remember if it was perpetual or annual.

However, I continue to be amazed that Perforce survived Git. I assume its ability to handle large binaries has been what saved it.

yeah i think it lives on in games probably mostly through inertia. last i looked the company itself had shifted away from p4 classic to some git wrapper stuff.

i've never actually seen it but my understanding is that google's custom internal system (piper) basically is a reimplemented scalable p4+g4 wrapper.

i always thought the workspace mapping and workspace template model in p4 was pretty elegant, especially for things like embedded platforms where you could opt in and out various subtrees which made very large device trees/bsps more manageable.

also they were the first widely deployed vcs system that attempted to be efficient (server side indices for local tree state and communication with the server in deltas rather than forcing complete rescans for every operation that often involved talking to the server as each file was scanned)

it's just not as interesting to me when it's no longer evidence of careful and deep thought paired with high quality execution and skillful craft.

plus all the claude-isms get old.

It seems possible they trained this by doing full RL rollouts of agents interacting with each other. They likely view these prompts somewhat the same as raw reasoning traces, they don't want people to train directly on them.

this tracks. anthropic protects these as well iirc.

I am unsure if this has been confirmed, but there are some signs that the opaque "compaction blob" they return from their dedicated compaction endpoint might not be text at all, rather a latent space representation of the conversation.

probably not a latent (to my knowledge latents aren't really part of the outer loop in ar-transformer inference processes), but maybe non-human-readable reasoning traces as occurs in fable.

how hardened are modern browsers with respect to detecting underlying os? seems like there would be loads of gaps?

it's kinda like riding an e-bike, but in heavy and unpredictable pedestrian traffic.

sounds like it is just supercharging the business of science with all of its known failings?

it would be funny if by accelerating the enterprise it actually forced an effort to correct the trajectory.

even though there's still a lot of work to push things over the finish line, i have enjoyed how much it has reduced the activation energy for starting and finishing "one of these days..." projects!

it will be interesting to see if any new formats emerge. if ai kills the take home, what can replace it for similar "let's see how far you can go if you have resources available" style examinations?

maybe we'll see specialty chatbots that give the equivalent of oral examinations and/or are willing to provide reference material but not make suggestions, connections, solutions or generate prose on behalf of the user?

cool to see rustdesk. low level memory bugs were long mysterious and i think often received most of the attention for this reason, but always fun to see reminders that "nope, good ol' fashioned logic bugs in high level languages have security implications too." if anything, i think they sometimes are more clever as they require deeper understanding of what the code actually does, intends to do and what was overlooked rather than the common set of bookkeeping errors that are often the root of the memory bugs.

i wonder if it's about protecting it from extraction/distillation or if it's about not having to answer for surface that hasn't been properly vetted for public consumption. (ie, is someone going to sue them or complain or write blog posts because the thinking has transient things that people don't like where the final result is what is actually vetted?)

i agree with the author. i argue a preference for loose coupling over centralized abstractions. sure it's pleasing to compress the code, but if the use cases actually are sufficiently divergent (as well as bugs and externally driven changes) ultimately it becomes brittle, littered with edge cases behind if fences and both challenging and daunting to change.

ideal case: support libraries and then very simple duplicated code that is easy to read and modify. critically the core control flow should remain duplicated, but simplified by the support libraries.

my first reaction: this pivot makes no sense at all to me.

my second reaction: maybe it does? did they hire up an army of physicists to make better diffusion models or something and they actually have people on staff who can do this?

that's how i understand it. it's a portfolio with front matter, back matter, the papers that got published with some connective tissue between them and maybe some discussion of the things that didn't work out and why.

symbolic music features are interesting! they should add chroma!

yeah, i think you're right. i originally read a bit of snarky blow-off, like "eh?" ... but you know, now that i think of it, it's actually does have more of a friendly canadian style vibe.

the '90s version of finding the hiring manager or boss on linkedin to try and get a job was connecting to the company's public smtp server with telnet, using their name to probe different email address patterns with "rcpt to:" (those days the actual servers were often directly connected to the internet and would leak email address validity in how they would respond to rcpt to) and then sending them a nice email.

smtp grew up to be an antisocial curmudgeon. extended smtp starts with EHLO.

because in those days there was no curl, or wget. and then when there was, there was no guarantee they'd be installed.

telnet was always there though. it also worked for speaking all the other plaintext internet protocols. (imap, pop, smtp, etc)

it's not that insane. i've been manually typing http requests in since before http/1.1 and the mandatory host header.

it is insane to use it for anything serious (also the opposite, implementing webservers in bash), but for quick testing it's pretty great!

blindly trusting upstream is not really a reasonable posture. that is pretty much the source of all software supply chain attacks.

there is work involved in figuring out how to get the complete diff of the code and dependencies that are included in the change, plus review time. this could range anywhere from 5-10m to 1h per package updated- if not more.

pretty much all of them. the diffs only really show that it's coming from the same source, the changed hash and maybe some urls for some patches. actually looking at what is in that changed hash is a much more complicated story. this gives end users a false sense of security ("i read the diffs" -- not really), and attackers a clean vector (all it takes is one bad commit that might not even be on a real branch, or linked patch or late download dependency in the package itself).

i read all the pkgbuild diffs, still doesn't give me a good sense. sure, i can verify that it's coming from the official repo but even then there's no guarantee that there isn't junk in there or that the git ref is actually pointing at the right thing.

it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture.

two scenarios i could think of where there's additional risk for bio/nuclear weapons 1) basement lab leaks and 2) improving quality of execution for shops that are already resourced enough to hire experts but maybe they're not that great.

i think the correct answer is probably to funnel more money to global (bio)security initiatives and maybe use ai leverage as a way to get more of the world on board. (some kind of access to nvidia or cloud ai or whatever in exchange for policy commitments deal- while that leverage lasts).

  i built a turbofan
  https://app.confbuild.com/p/z459
  
  now I want to build a complete Airbus as detailed as possible with give budget

the claimed inference cost is 2x. if that is true, it is massive and remarkable that they're able to do anything like this at all.