schobi

It is still going to be many amps.

The capacitor circuit has the advantage that could can't mis-drive. If a transistor of the half bridge stays turned on for longer than the msec required, nothing will happen. The half bridge chip (usually) already prevents that both transistors are enabled at the same time. This is great when you develop firmware and might end up with one pin staying high for too long.

With a direct drive, the flip dort magnet wire could quickly burn through if you leave half an amp for too long.

Oh - but only touching them?

I was hoping for an iteration of a factorio belt that could actually move!

I can imagine the other internal teams looking at this.. "100 TB gets you attention? Hold my beer.. we will try that as well!"

I'm puzzled as there seems to be a clear pattern on how a human user would look like vs a bot.

High bot likely hood if: If a session jumps to a different ip. If the session jumps IP after just a few requests. If a new blank session starts with a deep link. Maybe those are cases where some POW is better justified?

Assumption: the rendered HTML might be viewed by a legitimate developer, even via a deep link from outside. But rarely from a wget script without a session cookie .

The other nice idea from the comments - is this rendering effort something that can be pushed to the user? Instead of pointless POW work, can you offload the expensive rendering to the user side?

But certainly, this is just an armchair comment and the kernel guys certainly have tried everything in this arms race...

This hints at a hiking trip planner maybe? Depending on time of day and year evaluate a path to be in the direct sun/shade?

In summer, I might want to avoid the direct sun. Suggest the hiking path with least direct sunshine. And if it is autumn already, then please suggest a hiking path to be in the sun all day.

Might be a cool feature to compare hiking paths by percentage of direct sunshine.

But maybe, selecting a path through a forest vs. across open fields might already do.

Great result - it would be nice to learn how this could be used..

How would you connect a Tamron lens to a Linux machine? Is this with the external USB port or Bluetooth dongle? Or through the bayonet connector? A linx camera controlling it's lens?

Just for settings and firmware update? Or some imaging workflow? Can you give a practical example of Linux also controlling the camera?

I think this is a clever idea.

A hub motor for each leg adds some weight, but you get a rolling mode on flat terrain with great range.

At the same time you keep obstacle climbing mode with stationary wheels, and can use the leg actuators as shock absorbers and obstacle avoidance on a bumpy path. Best of both worlds, with a new software challenge.

I tried to think about difficult ways to compute the high frequency coefficients to work from the "wrong" coefficients of the first image...

But this is clever - just smash them together. Low frequency of one image concatenated with high frequency from another. This works surprisingly well!

Both your points hold.

The distinction is rather that the device was made next door, from raw materials, with them possibly watching. Certainly acknowledging the craftsmanship, but still while understanding your tools.

Today, labs are filled with expensive machines and you are not able to peek inside. You need something? Only from a catalog, made in a mystical factory, without you knowing what's inside.

This abstraction speeds up your process (the tool you bought is fully qualified for what you plan to do) but also detaches you from the low level inner workings. Kids are fascinated if you take an everyday object apart with them (but maybe only if it was already broken)

The linked article is a high level announcement that new sensors were installed, but no experiments yet.

I would have loved if they shared some technical details, e. g. which sensors, how does it record, frequency range and sample rate, time synchronization, offline capabilities. Maybe even a photo of the sensor? (I couldn't find any)

I'm surprised there are no security researchers that would pick up on this.

Take the same prompt and all incoming mails and run again through various existing models, even the simpler local ones. He now has a serious cross section of prompt injection ideas. This is a publication I would like to read!

For privacy reasons I understand the corpus might not get published. But for a research collaboration and safeguards (don't send automatic answers from each model you try)... why not?

I guess the decoder is more than the 208 bytes that this page uses..

But maybe you can misuse this and store a session ID / cookie in a favicon (give everyone a unique one) and survive some cookie cleanup and evade privacy restrictions?

Maybe you can still make it that the favicon looks like an image a little to not raise suspicion?

Favicons seem to be cached across private browsing sessions. Oh no

This post describes how to take an off the shelf VT100 serial console emulator and connect a USB keyboard and VGA monitor. This device https://www.tindie.com/products/retromodem/dec-vt100-mini-te...

This post spends a lot of attention on how to fasten, glue and adapt a specific existing keyboard and monitor from a 1U rack mounted console. If I would need a similar serial console, it will end up differently - just because my parts are different.

I guess this was more related to syncing GPUs.

If you were to take 500 computers with older 1080 GPUs, you might have enough compute/ram equivalent to an H200 GPU for training such a model. Maybe take 10000.

But if those machines are spread over 10000 homes, wired with residential internet service, training a large model will not get anywhere.

You go from "data in the same HBM memory chip" at 4.8TB/s or "data in adjacent GPU" with NVlink at 1.2 TB/s down to 25 MBit/s upload speed. Accessing the next piece of data is going to be about a Million times slower. At the same time you will heat a thousand times more, for a Million times longer.

I see another advantage..

You can switch a motor without permanent magnets to "idle mode".

I understand in Tesla dual motor configurations, the front motor is without magnets. The excitation field will be turned on when you need extra power, but at crusing speed it does not cause extra "drag". From one teardown I've seen, they even went so far to use cheaper and less efficient IGBTs for the front drive, and more efficient SiC Mosfets for the rear motor (in the same vehicle!). If you need extra acceleration briefly, lower efficiency can be accepted.

Well.. The automatic part comes from the camera directing the settings mostly. The lens would be motorized focus/aperture.

For motion picture cinematography, I've seen remote controlled focus anyway. I don't see why you could not have a good motor built I to the lens and remote control it. If the external motor focus is quick and precise enough, then the internal motors should be as well.

Good writeup and solid presentation of wifi timing experiments.

With his typical product-ready development and polished descriptions, I'm glad there are also some unfinished ideas in his drawer. (my imposter syndrome)

I'm already annoyed by the marketing to call it fullspectrum - this seems to promise more than demonstrated. Maybe call it "CMYK printing"? I was hoping to see them printing a photograph (either on a horizontal or on a vertical surface, unlikely to work well on a ball). I was also missing a continuous gradient - so far, only colored patches?

I'm hoping for the next innovation with mixed extrusion to reduce print times. We are lacking an automatic extrusion amount and nozzle size mixing within a "layer". Not just fine layers everywhere with mixed colors on the inside.

Goal: print the infill and inner perimeter from a larger nozzle and thick layer height. Use the fine nozzle and fancy layer-mixing only on the outside where needed. It is not going to be strict layers any more - I understand, this makes it difficult certainly. Then the Prusa printers could shine that exchange fully loaded and pre heated print heads quickly.

Until then, I'll happily wait for 2 days to get a spool of orange filament delivered.. Instead of waiting for a 20hour print job

I'm impressed by the coding skill to achieve a seamless integration and "usability".

But other than a demo "because we can" I'm confused on what this could ever be useful for. AR/VR prototyping? Virtual showroom?

Or maybe for an online presentation? Stream a video of playing Minecraft and get fancy slide transitions? "let's go to the next slide" and "now we enter dangerous territory".. "over here I can show you how this program looks like in real life"

I would expect that this leads to cases where the game is handed over to a shell company that goes bankrupt. The shell does not have the rights to all parts of the code and can thus release only part of it in a state that is useless. Some parts might have a weird license attached and so on.

Escrow or demonstration upfront will raise the bar before releasing new games in California.

The paper shows a through analysis of write amplification and slowdown/wear with large databases (800GB) on a single machine. Databases are MySQL and postgres. As already commended, this can lead to an optimized storage table format for greater performance. Nice!

I would expect that a similar analysis can be done for sqlite, maybe with a different dataset, single write thread..

Summary: dry contact with nearly any laboratory glove will lead to sample contamination and over estimation of microplastics. They found one type of clean room gloves that contaminate less.

Is there any indication on how bad this really is?

This would have been nice if code was included, but I did not see it. It is just the statistics of the specific Kodim dataset, that was once published on a Photodisc.

Use cases for this? Maybe to validate you own statistics computation?

The Kodim dataset is pretty useless nowadays. If you build an algorithm that runs on this dataset (or the Lena image) it will be pretty bad on other images. Think of data dependent things like compression, segmentation, inpainting or such. The specific characteristics of these "small" images are unlike a cellphone Jpeg or DSLR raw.

Brilliant to get this done all the way through.

Once you introduce a HDL and start optimizing, I would expect more than half of the transistors to be redundant. But you would end up with a circuit that you will not understand any more.. But that could give an important lesson in chip design and HDL compilers.

Well... I have a hard time imagining to get location by yelling "where are you? " "by the trees!" It really sounds immensely useful to know last location (while they were still in range).

Use case: I was out, picking wild lingonberries in the forest with a group of ~10, some kids. At a "secret" location, with everyone wandering off in a direction they see more of them. Shouting did not help much.

Maybe I skipped over it, but the (suspected) narrow band emission of their diodes is something that could be detectable.

Electronic warfare is not about listening, but just seeing the location of the emitter. If you had someone with a different thermal camera/ camera with SWIR, you might see that something is just not right.

Christopher Helmke just shared another trick https://youtu.be/tSvwcUbL95Q?si=YunTp0p5Duu754cX

It is a clever mechanism to separate a wide range of parts. Like a vi Rating feeder, but without adjusting the device for different object sizes. It is a rotating tube, slightly angled.

How would that help? Say - you have just one tube to seperate parts. You drop your first box of washers and route them into a sequential storage. They you do the next box with bolts on the same device and drop them into another sequential storage.

They dispensing remainds still manual as mitxela showed.

A beautiful balance of effort and benefit.

I don't know any better, but the screw counting mechanism seems awkward. Imagine the set has 10 components..

I'm surprised there is no standard solution to this - like a tape and reel solution? A counting and dispensing gun that works for different sizes? But how much more would anyone pay for M3 bolts on a tape?

Helmke had a tube feeding his dispensers in one of the videos, with bolts lengthwise. That tube idea could be used for a manual dispenser - imagine a drink dispenser, but giving 3 bolts. Maybe easier to store away, but just as awkward to load.

Image and video compression has become a field that is painfully hard to enter. State of the art is complex and exhaustive, the functionality of reference encoders and comments/versions among them is really a lot.

We are well beyond where a dedicated individual can try an idea, show that it is better and expect that others can pick it up (e.g. in standardization). It is not sufficient to run a few dozen images and judge by yourself, you are expected to demonstrate the benefit integrated into the latest reference encoders and need a sponsor to join standardization efforts.

For educational purpose? Sure - do whatever you want - but any discussion "is it novel" or "is it useful for others" is moot, unfortunately.

I applaud the effort of tinkering, re-creating and sharing, but I think the name is misleading - it is not at all a "local GPT". The contribution is not to do anything local and it is not a GPT model.

It is more like an OpenClaw rusty clone