pveierland

It is using JavaScript for user interface customization via:

https://gpui-kit.com/shell/

I'd love to use more brotli and zstd, but for some reason browsers seem to support these in fetch requests but not in the DecompressionStream API, meaning that you need to bundle your own decompressors if you want to do this for other use-cases.

https://developer.mozilla.org/en-US/docs/Web/API/Decompressi...

Mandating and accepting broad use of text watermarking at scale seems prime to enable all sorts of dumb and chaotic downstream effects. Not only do you start to pollute further corpus at scale - hijack text space bandwidth and fidelity - but you open the societal door to gradually add additional pieces of information - such as author identities or ad tracking information - which can then not just directly reveal a single author, but potentially larger graphs of information propagation without it being clear to anyone propagating such a trace.

One excellent update that comes to mind is their updated code search (2023) which can be super helpful and respects a solid grammar.

https://github.blog/news-insights/product-news/github-code-s...

> While Fraser's explanation was technical and specific, he hit a light-hearted note to summarise it: "LLMs [large language models] won't wipe out humanity because they just don't have that dog in them."

Never underestimate the drive of a good while loop.

Funny that this is the only Dropbox post I've seen on HN besides infamous references to their launch post. You'd think there would be plenty of interesting improvements to make.

Having been a paid user for the last decade my current experience is just getting error messages on my phone every week that something failed to sync, and that I have to re-enter the app every ~month to disable/enable syncing for my offline files, otherwise it doesn't work. I can't remember any time I've been pleasantly surprised by any change to the service.

There's new CSS capabilities [0] that can help solve this problem better now via alignment-baseline [1] and text-box-trim [2].

[0] https://www.w3.org/TR/css-inline-3/#leading-trim

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

[2] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

They are clearly progressing now as a project and the world definitely needs what they are building - it's literally something you can download and run right now.

Rust was started in 2006 (20 years ago) and is now one of the most powerful programming languages, while the Servo project was started in 2012. If they reach parity and beyond of current browsers this could clearly become one of the most important browser engines in the future. Effort very well spent in my opinion.

I don't think it's an either or - additional data signals that need to correlate to authenticate will increase confidence. You can use multiple other signals to evaluate whether something is truly a landscape photo, and in that case not require a LiDAR capture, but if you are inside and at close range then you could assume that it should be part of scoring the authentication.

Similarly, LiDAR alone will help disqualify cases where someone is just taking a picture of e.g. a landscape target of the Golden Gate, but that it shown on a screen 1 meter away.

Still, that means that either the fake target scene and your screen presenting it would need to be outside of LiDAR sensor bounds, or you'd need to find a way to make the depth sensor data conform with your fake scene, both increasing the difficulty of producing a forgery.

Claim 7 in this patent application describes how depth sensors are used as part of an image authentication process, which would make such a workaround more difficult:

https://image-ppubs.uspto.gov/dirsearch-public/print/downloa...

The Apple Reference Image feature is here launched on iPhone 18 Pro and iPhone 18 Pro Max that both have built-in LiDAR sensors that could be used for this process.

Garage added an automatic configuration feature in v2.3.0 that makes it easier to set up single nodes:

  garage server --single-node --default-bucket

https://garagehq.deuxfleurs.fr/documentation/quick-start/

Amazing how concise the code is! There is something about Lisp that feels very pure and ethereal.

https://github.com/modus-lisp/brotli-pure/tree/master/src

Websites could use it to implement less power consuming behavior when you are low on power, e.g. defaulting to run an expensive computation when requested instead of automatically.

Ignoring browser fingerprinting, it seems like most of these signals could be used to implement some feature benefiting the user.

Clearly not. A person posting a picture is performing an explicit act of sharing a specific piece of content. Even in the case where the person doesn't know what that entails, they have made a choice to share specific content. With smart TVs it will be unclear to the person that recording is even happening, much less how that data is used and for what purpose - so the likelihood of them realizing that data is being shared or that they need to show consideration for how data about others in presence of the TV is shared will be close to nil.

Just package it as "decayfs", a FUSE that corrupts stored data each time files of these formats are read.

Refreshing to see model announcements without claiming #1 in some benchmark. The amount of documentation seems very immature [0]. No system card provided - compared to Opus 4.8 which shipped with a 246 page analysis [1].

[0] https://docs.x.ai/developers/models/grok-4.5

[1] https://www.anthropic.com/news/claude-opus-4-8

I don't think so at all. Models are trained in many ways and are changing aggressively, resulting in different patterns in different regions, domains, languages, and will be different 3, 5, 10 years down the line. Having everyone try to learn and adapt around how to stay within very magical, fuzzy, and ever-changing boundaries to avoid appearing to be an AI, instead of focusing on producing good writing or communicating as it is natural to them, seems like a recipe for bad thinking and arbitrary reactions.

Nice! That sounds like a good change. I'll try to dive a bit deeper through docs once I find some time :)

The syntax is of course attractive (coming from Rust), and I'd love to replace more of my posix scripts with something saner. I struggle understanding whether the utility of having language literals for IP addresses, IP prefixes, and AS numbers is worth it though [0]. It seems like the confusion added by having custom built-ins like this for one particular domain, in addition to the unclear scoping (what could later also deserve being a language literal), combined with special-case errors as famous in e.g. the YAML Norway problem, makes it seem like such features are better left as some general extension / macro / library capability.

Nix is a language with built-in support for URI literals typed as strings [1], which is a source of confusion and edge-cases, and I believe the feature is now discouraged in general use.

[0] https://roto.docs.nlnetlabs.nl/en/stable/reference/language_...

[1] https://nix.dev/manual/nix/2.34/language/string-literals

The Noto fonts have great coverage: https://notofonts.github.io/overview/

Shout-out to the React Compiler for those that have not tried it. It's very easy to configure and can automatically deal with many cases of useMemo / useCallback / memo to reduce boilerplate in code: https://react.dev/learn/react-compiler

The term non-player character (NPC) will become ever more relevant. I used to dislike it as I felt everyone adds signal, but if all you are doing is relaying information then that is effectively what you become in that context.

One issue with this argument is that there are very few engineers that have had the opportunity to design satellites that are; this large, are designed for mass manufacturing, rapid iteration, failure allowance, and with access to a reusable launch vehicle with the capability of Starship (where it's also unknown what launch mass capability they will end up reaching).

The satellites built by SpaceX so far, and their engines, are quite unlike most previous space engineering due to these reasons. Given the undeniable success they've had in building Starlink, with each version growing considerable in size, I just don't see which engineers would be able to fully rule out the math that SpaceX might be working on here, exactly because there are so many parts of the total equation and where SpaceX are moving outside the previous design envelopes in many dimensions.

Of course I'm personally not convinced or able to know whether this is economically sensible - I just believe it's very difficult to fully rule out given the track record of SpaceX - and given that there doesn't appear to be any singular insurmountable thing that needs to be figured out here. Hence why I said in my original post that this is why I'm excited to see the design space explored.

> The point is that they're absolutely not in isolation from other challenges because designing something to radiate heat at maximum possible radiative cooling efficiency is not considered to be a problem, solving the unit economics of launching the required radiators tonnage and burning 100 tonnes of rocket fuel to per tonne launched that's the problem.

I was pointing out relative coupling, not absolute coupling. The coupling between the different design decisions involved in Terafab or Starship seems far greater as there are so many design levels to unite jointly - while figuring out the structural and thermal design of these satellites appears to be something that to a greater degree can be resolved with less design constrained coupling - i.e. making it more feasible to figure out with a lower number of people.

> Optimizing for local circumstances is a benefit to doing things on earth: if having a production line and the ability to plug into wherever energy happens to be cheapest was better we'd all be sticking inference chips in shipping containers and not worrying about HVACs being relatively inefficient at cooling.

I did not reference energy cost directly. In many countries there are year-long lines for data centers to even be allowed to connect to the grid, which is why many also resort to local gas turbine power plants etc. Having a cost effective (the unknown is if/when this becomes possible) method of deploying large units of compute without dealing with this power access issue - zoning issues - local policies etc - appears to be one of the large attractions to this endeavor, in addition to being able to avoid longer term scaling issues. Inference sticks are not cost effective at scale now and that does not seem to be on the horizon. Space based compute however seems to be a more open question depending on your timeline.

I read the comment that I replied to as these challenges being a large prohibitor to this development, and I pointed out that these seem like challenges that can be dealt with mostly in isolation from other challenges and in particular not require a large number of engineers to deal with.

Of course the major exercise becomes about total cost efficiency, but I think a large attraction is that once you've solved space deployment sufficiently, you don't need to keep dealing with local circumstances and power production adaptations to every new site you're dealing with on Earth, as it's more about producing a set of modules you can keep launching without individual adaptation - not about "space being cold".

As problems go, radiation and cooling seem to have relatively low dimensionality compared to the other problems. It seems to be mostly a question of optimizing within the dimensions of dissipation / structure / deployment / service / cost / weight. When all is said and done, the cooling solution will end up being a module that can deal with some power dissipation, cost X amount, weight Y amount, have structural interface Z. This seems like something a relatively low number of engineers can iterate on largely isolated from other concerns. SpaceX does have 5000+ of them.

Comparing this to scaling the production of compute where they try to work outside the bounds of ASML (~40k employees) and TSMC (~80k+ employees), and where there is a huge number of degrees of freedom in many, many layers of the stack that have complicated interactions.

With radiation and cooling, SpaceX also has plenty of experience with both already given that they've had to solve this on existing satellites. Overall, Terafab just seems like a far harder challenge, and where I'd be more wary on timelines.

I fully agree on the reality distortions and valuation chaos surrounding Tesla. This does also follow from the company being very volatile and chaotic, which becomes harder to price. How do you accurately price in e.g. Optimus - it seems really hard to tell at this point - which I guess is also one of the motivators for these strategies.

However, in this particular trajectory, SpaceX did build the rockets and did build Starlink which is now the best global-scale wireless communication network for many use-cases. Stretching this trajectory to scale up the technology to facilitate in-space computing is vastly more grounded than Shakespearean monkeys.

Beyond aggressively optimistic timelines, I find it difficult to disagree with the premise. The aggressively optimistic timelines is also what makes it feasible to even attempt these things, where e.g. the amount of iteration required for Starship would have broken most other companies.

> In the long term, space-based AI is obviously the only way to scale.

In the long term - all mass and energy available is outside of Earth - what is here is not even a rounding error. If you wish to continue scaling compute it then becomes a question of time before you'd want to go off planet. Personally I'm quite keen to see near term space based compute explored, as it could end up becoming a much better trade-off than allocating ever more ground to power and operate terrestrial compute which directly conflict with the biosphere.

SpaceX started the Starlink design phase in 2015 - started launching Starlink satellites in 2019 - and they now have the most dominant satellite constellation ever deployed by a large factor. They have their own launch systems, launch sites, satellite bus, communication stack - both in-house designed and built.

What is really going to be that difficult with space-based compute? Radiation hardening and cooling? These are clear engineering challenges that can be simulated, tested with earth analogs, and then rapidly iterated across design generations. There's napkin math all over the internet on this, but it really seems like small challenges compared to the other engineering SpaceX has already sorted.

Beyond radiation / cooling / servicing - it seems like the biggest hurdle is to crack the scaling of designing / scaling the necessary amount of compute they will need to scale space based compute according to the laid out plans.