A bit off topic, but I think I'm starting to get model fatigue. These come out 10x faster than new Javascript frameworks were coming out 10 years ago (at least new models are far easier to adopt).
There was a time when every new PC CPU coming out was a giant deal: "Guys have you heard about this new Pentium processor, it's incredible?"
But over time, more and more people got into the chip-making business, and the big players started releasing more and more chips. Now only the die-hard CPU trackers worry about every new CPU and exactly how it's better ... while everyone else just worries about "which CPU will be good enough at this moment".
Same for smartphones. There was a time of unlimited hype and secrery around new iphones. Who remembers the story of an iphone 5 prototype left a bar. Journalists were going crazy, people were signing petitions for Apple to not hunt down but instead forgive the employee that made such a grave mistake. People were offering millions to buy the prototype so they can brag they got the new phone 2 weeks before everyone else did.
Or who remembers the dancing disease of 1518, were people would stop what they are doing and start randomly doing the same dance. The lords? Out of their minds. The priests? Terrified the devil had taken hold of the flock!
I have come to believe that it was probably some tik-tok like hype trend of doing a fortnite dance while waiting in line for bread and communion. And the energy back then, like now, was off the charts.
Hype and memetic trend seeking encoded deep in human psyche.
> Who remembers the story of an iphone 5 prototype left a bar.
That was the iPhone 4 actually which was special for having the first “retina” screen. It was in a case to make it look like a 3GS to be used for field testing. The journalists that got their hands on it and published about it before the announcement could not turn it on past I think the Apple logo and a message saying to return it to Apple (or maybe it was just completely off, my memory is fuzzy), but were able to confirm the pixel density via microscope and I remember it blowing everyone’s minds at the time.
> people were signing petitions for Apple to not hunt down but instead forgive the employee that made such a grave mistake
FWIW I asked about it when I worked at Apple and he was indeed not fired and I think may have even still been working there when I was there around 10 years ago (though don’t quote me on that last part, he may have left already and I’m misremembering).
He was apparently not fired or even really reprimanded since it was a genuine accident and he wasn’t the one that sold it to the press, but that did start a slew of new policies around accounting for work devices.
I had dev fused phones for open carry outside of the office while I worked there but had to register when I got them and when they were returned, which apparently didn’t used to be tracked so tightly until that incident according to my coworkers who had been there longer.
Honestly, you don’t have to pay attention. What you do with models matters way more than the models themselves, and you don’t need frontier for the vast, vast majority of use cases
You might want to follow this proposal, if you aren't already. It's the most recent one, and it's supported by quite a few “core members” of the Go Team. I don't think it'll land in 1.28, but I like the fact that it's still a feature that's being actively discussed.
Having worked a couple of greenfield go shops post generics, it’s still quite rare to find them in first party code. They’re just not that useful outside of library APIs. Proper algebraic data types would be a huge game changer.
Go is extremely easy to pickup. If you know any language you probably know Go already for the most part (channels notwithstanding).
I wouldn't say it is a "beautiful" language however. Though that is in the eye of the beholder, I don't think the Go designers were even really going for beauty.
They were going for readability. You can make some impossible to read code with C++ because the programmer was too clever, and the designers of golang wanted to avoid that.
They were, very unfortunately, outsmarted by said too-clever programmers. As such I would like to request my enums and ternaries be returned to me. Trust me, they will not make a dent in the messes people have still managed to create.
This is only a small piece of the story for what people say when they want tagged unions. Without all of the ancillary support in the language, like exhaustive pattern matching, it really doesn't count.
The C++ committee said the same thing, and gave us std::variant. They are painful to work with and do not really deliver most of the benefits people want.
That is a LOT of code (very ugly code, I would add) that could be replaced by `type Float = float32 | float64` in a language with actual support for union types.
Tagged unions are not union types. A union type is a supertype for any arbitrary collection of types, but a tagged union aka sum type is a single type with multiple data constructors, and does not require subtyping to be implemented.
Another pet peeve (which this doesn't solve): Recipes that include "marinate overnight" or some such in the middle (which can be easy to miss), instead of telling you up front that you have to start the day before.
You're supposed to read through the recipe before you start. Also, most modern recipe books and websites put prep/cook/total times at the very top, so if you have to marinate overnight it'll say "total: 13h" or something like that.
And you can take a shower in one minute, but it won't be a good one. Proper onion caramelization takes up to 45 minutes, if you want its deep flavors and aromas. Anything faster means cutting corners, and some chefs will even save time bypassing the caramelization by adding sugar.
Of the sugar you've just added. Onion caramelization is a complex process, a prime example of the Maillard reaction. It involves several chains of chemical transformations, while the added sugar is only a step away from caramel.
> help things along with a little bit of sugar. In science speak, caramelization is the oxidation of sugars. Here, those sugars are the natural sugars in the onions, but the addition of a small amount of white sugar adds an extra caramelization boost.
I don't know about "chefs", but line cooks who haven't been to culinary school are generally trained to call this kind of faux-sweetened sweated onions "caramelized." Because, when a recipe calls for "caramelized onions" (and isn't an all-day background task like making a pot of onion-soup stock... which isn't generally something they'll be tasked with anyway), the onions as shown in the video are precisely what they'll be told to make. (Because it's fast. And because, for many recipes, it kinda-sorta works.)
That being said.
Caramelized onions should be a dark (nearly black) and warm brown color, not a neutral clay-soil brown. (Picture brown-sugar boba pearls.) They should have no water content, and should be visibly syrupy in texture. They should smell buttery + nutty + toasty; and should be extremely sweet, in that complex caramel way, with no trace of the original onion flavor remaining.
The onions in the video are none of those things.
These properties are all corollaries of what caramelization is, when it comes to onions: you're not only breaking down starches inside the onion into sugars, but then also fragmenting some of the resulting sugars into volatiles (diacetyl, furfural, etc), while polymerizing more of the resulting sugars into various caramel compounds.
The onions in the video have merely finished the first step: sweating. The cells of the onion have broken down, releasing simple sugars and water; but despite a few minutes' pan frying after breakdown, they're still wet and gloopy (and have quite a bit more cooking to go before they stop being so), because onions contain rather a lot of water, and rather a lot of sugar, and simple sugars are hygroscopic, i.e. they really want to hold onto nearby water.
The goal of caramelization is the same in an onion as it is in candy-making: you need to heat the sugar up until it melts and begins to react with things around it, both building up (polymerizing) and breaking down (fragmenting.)
Sugar melts well above the boiling point of water. So you can't caramelize anything until all the water is gone.
And that's why caramelizing onions takes around 40 minutes. 10 minutes on high heat to sweat the onions (as in the video); 20 minutes on med-high to drive off all the water; and a final ~10 minutes with careful watch-and-adjust temp control to actually caramelize the sugars, without burning them.
---
In theory, you might be able to make this process happen faster... but not with any random store-bought onion, the day you buy it. You'd need to 1. freeze, and then thaw, the onion (to break down its cells), and then 2. desiccate the onion (i.e. keep it in a bone-dry environment with convective air) to pre-purge the lysed water from it. The result would be a "ready-to-caramelize" onion that would let you skip the first two phases of cooking. (The result would also now be incredibly non-shelf-stable, becoming a pile of mush after a day or two.)
Some people throughout history (who perhaps originated the idea of being able to caramelize an onion in 10 minutes) may have done both of these steps purely by accident! In fact, insofar as onions are storage vegetables often kept in a root cellar for months before consumption, and insofar as some root cellars can both get to below freezing and be very dry inside, I could see most historical people cooking onions for winter recipes having gotten this "speed hack" for free without even trying.
But an onion you buy at the store will have gone through neither of those steps. Caramelizing an onion the day you buy it will take 40 minutes, full-stop.
Not sure if you watched all the way to the end of the video. At about 2:16, he shows the result along with the stopwatch from his phone set to 10 minutes.
In the comments from the original article, which you can find on the Internet Archive, he says that these these are not exactly the same as 45 minute onions and he would only use them a certain recipes.
And again, he's not the only one. There are lots of videos and articles about it.
I mean, I wouldn't have been able to precisely describe the result as it appears in the video if I hadn't watched it, could I?
And my point—I'll state it again—is that while these 10-minute onions might be useful, they are not "caramelized onions" in any sense, because no actual caramelization has occurred. And so saying that "this is a way to make 'caramelized onions' in 10 minutes" is false.
These are, certainly, a 10-minute substitute for caramelized onions; but they can no more be used as an argument that "you can make caramelized onions in 10 minutes, actually" (as the GGP poster says) than the existence of rice pilaf is an argument that you can make risotto in 10 minutes. They're different things!
Yup, I wish they'd just be honest and say 'sautee onions for 10 minutes to a dark drown' or whatever. But if they were, I guess they'd sound less fancy?
I messed up a recent DIY construction project because I didn’t read it all the way to the end first. My chef wife comes in with “you always read the recipe to the end before starting”…
> Steps that don't repeat the quantities, making me scroll back and forth between the step and the quantity list.
Julia Child's cookbook has the recipe in two columns, one for ingredients and the other for directions. As soon as I saw it I wondered why every cookbook doesn't do something similar.
Julia Child would also be in favor of doing mise en place--measuring out your ingredients before you start doing anything.
Personally, and I say this as someone who has been trained to do recipe editing, I find this tabular system to be not entirely clear. Consider the first example--the instruction to mix is applied to several ingredients at least twice. The instruction to 'fold in' seems to apply to all the ingredients at once, which makes no sense. Normally, you'd mix the dry ingredients together first. Also, in this case, you'd probably want to whisk the eggs and sugar together first so the sugar starts to dissolve. It also doesn't give you a clue as to what 'done' means.
We occasionally (maybe once a year) use a meal service for a couple of weeks, especially if it's a busy week.
The recipes sheets they provide drive me absolutely nuts working from them, to the point where I feel like I have to re-write them just to get them into a logical order. They're done entirely differently from any recipe book I've ever worked from. For example I constantly find I'm missing steps from how they're mushed together under photos, so I get later through the recipe and it talks about using something I supposedly did something with earlier and.. crap, I have to go back up through the recipe sheet trying to find what I missed the first time through. I've never experienced this with any other recipe book I've read.
This has some lessons that apply much more broadly than to just airports (e.g. apps that make you jump through hoops and expect you to know what 2fa or SSO mean)
Or just anyone involved in communication at all. For example my condo management team has names for every part of the building that they just assume that everyone understands. They don't seem to understand that most of the people living here don't spend most of their time reading the building floor plan.
> Most generative AI tools, however, are trained on copyrighted and licensed content, and their output can include content that infringes those copyrights and licenses
To some extent, it feels like the genie is out of the bottle on this. There's so much LLM-generated code out there, and I'm sure plenty of it could be argued to infringe a copyright or license (though I think the legal bar for counting as infringement is set too low), that there's no way to go back and undo it.
That said, OpenJDK might be afraid that someone will decide to make an example of them because they are a high-profile target.
The part of this that's the most interesting to me is the fact that it is worthwhile for the compiler to expend the effort looking for this optimization opportunity. I would expect (x << 2) & -4 to be a fairly rare pattern, and even then removing the & -4 only saves one or two assembly instructions.
It's because the underlying optimizer follows patterns in LLVM, which is used for a lot of languages, most applicable here is C/C++, and bit things like this are used a lot for performance.
The particular patterns were added to C2 just recently, being copied from the implementations in LLVM and GCC.
Also it's unlikely the compiler looks for this in particular, but this falls out of a set of optimizations that do matter and it collapses into the output assembly on relevant architectures.
gcc and LLVM have also copied ideas from C2, and there's been cross-pollination between Java and C++ compilers going back decades. All three are among the most sophisticated optimising compilers right now.
Every optimisation like this increases the chance of other optimisations/vectorisations being able to usefully fire, and sometimes these very specific cases are themselves from optimisations or type/range restrictions.
One day I want to build something like this, except for sound. It would be great to get a heading and distance for where a sound is coming from.
This could be both for small scale things (e.g. which part of this is squeaking?) or large scale (e.g. is that booming noise coming from the construction a few blocks away?)
There are a few knockoff options too, which are not quite as nicely calibrated, but get the job done for much less than Fluke-level prices. Like the FOTRIC TD2.
These are the kinds of things you look at and think - maybe I DO need night-vision, or a soldering iron with a cpu, or a thermal imager, or a steerable endoscope or now an acoustic imager....
+1 to thermal imager. I use mine to locate hot wires, heating and cooling gaps in the roof and around windows, car maintenance, the pizza oven, and its even sensitive enough to ‘see’ studs in the wall.
Priceless on one occasion for finding leaks in the ceiling, which are notoriously hard to pinpoint.
Can also be used for looking at heat leaking into or out of your house via conduction, which can help you determine where there might be more insulation needed, or maybe a particular wall needs more shade in summer.
Has anyone tried acoustic imaging for water leaks inside walls? I live in a multi-floor 1900s Victorian. A leak can affect several units, and tracing the source can mean opening walls or floors in multiple places, and coordinating access has been getting harder with less WFH.
Could one of these tools help map water pipe routes and trace a leak, or are they only going to be useful for air and gas leaks?
Initially I scoffed, but then I recalled that certain RF bands are disproportionately absorbed by water and this is used for certain sorts of atmospheric imaging by satellites. So you'd need a moisture "light" and an RF camera. Other than being cost prohibitive it sounds like an awesome toy.
It still works pretty well in the IR band. I know that one from experience due to storm damage to our roof ;-)
A leak only turns invisible if the water has the exact same temperature as the wall and there is no meaningful evaporation happening (as that cools the affected area).
Of course don't let me stop you from actively probing your all using RF. Though also there you might have good chances with IR, since wet $stuff should behave differently than dry $stuff ;-)
There is a man call leak detective, who hunts for leaks in the UK. one tool he has is shutting off the water and filling the pipes with gas and using either sound or gas detector to pin down leaks.
Up until the 90’s airline in flight entertainment use stethoscope style earphones. My dad used to steal them for his workshop as a way to hear for leaks in various parts.
Our ears and eyes are very high bandwidth sensors.
Not sure if you've heard of them, but they're starting to come to market with this exact thing aside from distance detection and more on the "which part is squeaking" side.
The army has one of these for sniper triangulation, and Boeing made a civilian version for optimizing sound dampening on the 787. I don’t know if they kept doing that on subsequent planes but I would expect so given how enthusiastic they were about being able to apply the weight budget to greater effect.
You need really high clock rate sensing to differentiate the arrival time for sound from microphone arrays where they are all less than a nanosecond separated from each other.
A nanosecond? The speed of sound at sea level in dry air is approximately 330m/s. So at say 3.3 kHz, the rough logarithmic middle of the audible spectrum, K=2π/lambda is 2π/0.1 m=20 π rad/m. A phase difference from a source difference k. ∆r would therefore likely be far more easily resolved than that for many physical ∆rs then, no?
Sensors around 12.5 inches apart will be a millisecond separated. The actual device was from a fuzzy recollection of a picture I saw, was probably 700 microseconds across. But it was a sphere with many sensor so adjacent sensors were less than .1 ms of separation. They would have all the time in the world to calibrate such a thing.
My guess is rather than triangulation, they probably just find the two microphones with the widest phase separarion between their signals and draw a line back between them. I don’t actually know how much 3D sonic math they’re doing.
What I do recall is that it was tech that had recently reached the Cheap Enough to Use status at the time, which is about 20 years ago now?
Making the hardware is fairly achievable without having to do fancy things. but if you want >8 channels you'll need to make some custom interface hardware.
I wonder if it would ever start to make sense to burn an AI model into ROM, replacing a large portion of an inference machine's RAM with ROM. (Probably not, since I'm sure those machines do dual-duty and run training when the inference workload slows down)
That's the idea behind Taalas (https://taalas.com), except as silicon rather than ROM. They run a demo at https://chatjimmy.ai/ which serves an old open weights model (Llama 3.1 8B) at something like 15,000 tokens per second.
Companies are building chips specialized for inference, so dual use for training isn't necessarily a consideration, but there are other considerations such as:
Weights need to be loaded into the accelerator's processor fast, which means they need to be physically adjacent to it, but there is limited physical space for that - not enough to fit the all the weights of a 1T+ param model, so weights get loaded into VRAM dynamically according to what part of the model is being run.
ROM (I guess we're talking Flash memory) can be dense, since it is built vertically - many hundreds of layers, but this comes at the cost of poor performance, so even if you could fit enough ROM next to the processor it would not be fast enough.
Yes that's the language, the v0.10.0 benchmarks are coming very soon and with it some major updates. We've added supercompilation and symmetry breaking to the optimizer pipeline. Sneak peeks available on a branch currently named stream1. https://github.com/Brahmastra-Labs/logicaffeine/tree/stream1
reply