dgriffith

joined 2 years ago
[–] dgriffith@aussie.zone 5 points 6 hours ago

but air resistance is a bitch. You wanna go twice as fast, you need four times as much power

Unless your supersonic aircraft is up a lot higher than your subsonic one. Coffin corner is a different beast when you can go above Mach 1.

So perhaps this will work out as twice as fast for only 3 times the fuel. An acceptable tradeoff, perhaps.

[–] dgriffith@aussie.zone 2 points 1 day ago

According to OpenAI, the agents eventually chained together multiple vulnerabilities, escaped their testing environment, gained internet access, and attacked Hugging Face while attempting to complete the ExploitGym cybersecurity benchmark.

This is just gross incompetence on OpenAI's part. It took days for the LLM's to do what they did. Meanwhile, nobody's looking at network traffic or wonder what the LLM's are doing sucking down a bunch of tokens.

exploit vulnerabilities at machine speed.

_Thinking......_

_Still Thinking......_

[–] dgriffith@aussie.zone 2 points 1 day ago* (last edited 1 day ago)

The article is quite fixated on how dialup was around in the early 2000s, and how Americans used dialup in the early 2000s with screeching modems, and how AOL turned off their dialup last year and only a thousand people were using dialup by then.

But there's no indication that this has anything to do with the application, except for maybe everyone used a popular means to connect to the Internet to use it when it was first built.

Now if someone maintained a bank of modems and people legitimately called them up and connected to the system like it was an ISP, and it was secure by way of that was the only way to access it as opposed to over the Internet, then sure, I can see that maybe it's time to work on that part.

[–] dgriffith@aussie.zone 3 points 1 day ago* (last edited 1 day ago) (1 children)

On disk 17 out of 37 of a Microsoft Office install in 1994:

GRONK-GRONK-GRONK-GRONK-GRONK

Disk error reading Drive A:

Abort, Retry, Fail?

[–] dgriffith@aussie.zone 3 points 1 day ago* (last edited 1 day ago) (1 children)

Firstly, suspend might be an option compared to hibernation for your subsequent startups if you can suffer a slow startup the very first time.

Otherwise look up "Linux from scratch" .

A lot of boot time is decompressing and mounting initrd, loading modules there, mounting the root filesystem, jumping to that.

Build a kernel that has exactly the minimum modules needed for your system, skip initrd and jump straight to a root filesystem and call your init binary (it can be BusyBox even) do exactly what's needed there to get your network+graphics card up and running with a single shell script, done.

Also look at COW filesystems. Read only base with an overlay file for writes. Discard that file on each boot and you basically have a system that is always at the same state on startup.

[–] dgriffith@aussie.zone 1 points 1 day ago

Only when the orebody happens to be on the top of a mountain. Plenty of deep pits to haul up out of as well, but an overhead lines+pantograph setup allows you to use grid power for the hard bit and battery power for the easy bits on the level.

[–] dgriffith@aussie.zone 1 points 1 day ago

Mining is a 24/7 operation. There is no "over night" rest period. You need batteries that can charge during breaks for workers and usually they have 3 breaks in a 12 hour shift.

So 4 hours runtime, 20 minutes back to full charge is a pretty good fit.

Never mind the couple of megawatts needed to charge a 600kW battery in 1/3rd of an hour. 2 MW is enough to comfortably power ~100 homes. Have a fleet of these on charge and you're drawing the same amount of power as a small town.

[–] dgriffith@aussie.zone 1 points 3 days ago

Then they wait.

Do you understand that your position is just like saying, but what if there's something in the hospital that the wheel based ambulance doesn't have!!

There are already "lightweight" critical care responders in small cars and motorbikes and such. Just a more agile mode of transport for those folk.

[–] dgriffith@aussie.zone 1 points 3 days ago

"Pulse can cover 2,800 square miles in under eight minutes and land on rocky terrain"

30 x 30 x 3.14 = about 2800.

So it's got a 30 mile radius, in 8 minutes, that's 225 mph.

So it's pretty speedy, but it's range is limited. I am assuming that it also has enough juice to be able to fly back.

[–] dgriffith@aussie.zone 16 points 4 days ago

CXMT will sell the chips to memory manufacturers in China for "domestic use only" at near cost price as directed by the CCP.

Those manufacturers will construct consumer ram modules and sell them locally, and there will be grey market exports to other countries for ridiculously low prices compared to everyone else.

This way the CCP props up domestic supply, and chips away at foreign manufacturer market share by turning a blind eye to the massive grey market export of RAM.

[–] dgriffith@aussie.zone 30 points 4 days ago

nationalize Micron

No, no, no, you don't understand, that doesn't happen in the US.

What will happen is that they'll get a trillion dollar bailout, a yuuuuge amount of protectionary tarrifs on overseas competitors and then some other company will scoop them up with no obligations.

And then - and this is very important - maximum profit will be extracted from consumers, who end up being measurably worse off.

 

Hi all,

In an effort to liven up this community, I'll post this project I'm working on.

I'm building a solar hot water controller for my house. The collector is on the roof of a three-storey building, it is linked to a storage tank on the ground floor. A circulating pump passes water from the tank to the collectors and back again when a temperature sensor on the outlet of the collector registers a warm enough temperature.

The current controller does not understand that there is 15 metres of copper piping to pump water through and cycles the circulating pump in short bursts, resulting in the hot water at the collector cooling considerably by the time it reaches the tank (even though the pipes are insulated). The goal of my project is to read the sensor and drive the pump in a way to minimise these heat losses. Basically instead of trying to maintain a consistent collector output temp with slow constant pulsed operation of the pump, I'll first try pumping the entire volume of moderately hot water from the top half of the collector in one go back to the tank and then waiting until the temperature rises again.

I am using an Adafruit PyPortal Titano as the controller, running circuitpython. For I/O I am using a generic ebay PCF8591 board, which provides 4 analog input and a single analog output over an I2C bus. This is inserted into a motherboard that provides pullup resistors for the analog inputs and an optocoupled zero crossing SCR driver + SCR to drive the (thankfully low power) circulating pump. Board design is my own, design is rather critical as mains supply in my country is 240V.

The original sensors are simple NTC thermistors, one at the bottom of the tank, and one at the top of the collector. I have also added 4 other Dallas 1-wire sensors to measure temperatures at the top of tank, ambient, tank inlet and collector pump inlet which is 1/3rd of the way up the tank. I have a duplicate of the onewire sensors already on the hot water tank using a different adafruit board and circuitpython. Their readings are currently uploaded to my own IOT server and I can plot the current system's performance, and I intend to do the same thing with this board.

The current performance is fairly dismal, a very small bump of perhaps 0.5 - 1 deg C in the normally 55 degree C tank temperature around 12pm to 1pm, and this is in Australia in hot spring weather of 28-32 degrees C.(There's some inaccuracy of the tank temperatures, the sensors aren't really bonded to the tank in any meaningful way, so tank temp is probably a little warmer than this. But I'm looking for relative temperature increases anyway)

Right now , the hardware is all together and functional, and is driving a 13W LED downlight as a test, and I can read the onewire temp sensors, read an analog voltage on the PCF8591 board (which will go to the NTC sensors), and I'm pulsing the pump output proportionally from 0-100 percent drive on a 30 second duty cycle, so that a pump drive function can simply say "run the pump at 70 percent" and you'll get 21 seconds on, 9 seconds off. Duty cycle time is adjustable, so I might lower it a bit to 15 or 10 seconds.

The next step is to try it on the circulating pump (which is quite an inductive load, even if it is only 20 watts), and start working on an algorithm that reads the sensors and maximises water temperature back to the tank. There are a few safety features that I'll put in there, such as a "fault mode" to drive the pump at a fixed rate if there is a sensor failure, and a "night cool" mode if the hot water tank is severely over temperature to circulate hot water to the collector at night to cool it. There are the usual overtemp/overpressure relief valves in the system already.

All this is going in a case with a clear hinged cover on the front so I can open it and poke the Titano's touchscreen to do some things.

Right now I am away from home from work, so my replies might be a bit sporadic, but I'll try to get back to any questions soon-ish.

A few photos for your viewing pleasure:

The I/O and mainboard plus a 5V power supply mounted up:

The front of the panel, showing the Pyportal:

Thingsboard display showing readings from the current system:

Mainboard PCB design and construction via EasyEDA:

view more: next ›