phire
Joined 15 years ago
Karma
8,871
Submissions
1,772
Member since
Mar 18
Recent submissions
Comment · 23 hours ago
Comment · 2 days ago
The DAO incident was a special case. It was only sane to do the rollback because the stolen funds were time-locked up for 28 days.
Ethereum never did it again, rolling back hacks didn’t (and couldn’t) become normal policy. IMO, they shouldn’t have made an exception, as it set a bad example.
I’ve seen a few other small projects attempt to do rollbacks since, but it usually turns into some kind of mess. In most hacks, the coins aren’t time-locked and quickly get laundered through smaller exchanges (and other services) which act as mixers. The stolen coins end up in the hands of a bunch of innocent people, and the rollback then causes way more harm as those users lose their coins.
Comment · 4 days ago
The lack of availability is basically the only reason they are releasing this new version.
They stopped making the lpddr2 dram that the old SoCs used a few years back, and now most of the stock has dried up.
The Pi 4 SoC used lpddr4, and I’m pretty sure they are still making it.
Comment · 4 days ago
The video has structures fading in and out of existence, which is a pretty typical artefact found in many AI video models.
That's not quite enough to prove it was AI in itself. But when combined with the fact he was unable produce the original raw grayscale video and how he deleting his linkedin... basically confirmed to be AI.
Comment · 7 days ago
> The original SimCity for example lists Intel’s 386SX as the CPU in it’s system requirements.
Not sure where that comes from. The original release box art [1] says it will work on any PC with 512KB of ram. So that's an 8088 running at just 4.77 MHz.
But that's far from the lowest spec port of the game. The Commodore 64 version might have been missing quite a few features (like stadiums, police/fire stations and railways), but the main city simulation loop was there in just 64KB of ram and a 1MHz 6502.
And the BBC Micro/Acorn Election port was even more impressive. Had basically all the features of the full Amiga/PC/Mac version, only missing Music/Sound/Animation. With a 2Mhz 6502 (or 1Mhz on the Election) and just 32KB of ram.
[1] https://images.launchbox-app.com/79861ce4-75ea-46dd-b46e-521...
Comment · 8 days ago
I think it’s really obvious that the ps6 won’t have an optical drive.
IMO, the main reason Sony are discontinuing ps5 disc manufacturing now is so by the time they get around to launching the ps6, the move away from optical discs is old news. They know the move is unpopular and they don’t want the drama associated with the launch of their new console.
I’m less sure about what will happen to bluray movies. But this is not a good sign.
Comment · 13 days ago
Based on this NSA documentation [1], they didn't actually synchronise the clocks with each other. They just tuned each machine's quartz oscillator with the nearest national time source. They were mostly dialling in the oscillator frequency here, not the exact time, so it didn't really matter they were synchronising to different national time standards.
Besides, even with the automated start system, the actual spin-up time of the turntables would have been a little chaotic. I suspect they were only aiming to get the four turntables within about 100ms of each other. The decrypted signal itself could then be used for the final fine-tuning of the timings (which also included adjusting for any speed-of-light delays)
If you weren't within 20ms, the operator would only hear noise (like a radio). Once they were within ~20ms, the operator would start hearing silence and would tune the phase until all noise went away.
You don't really need exact synchronisation because like a radio, the operator could just scrub the tuning to find the silence.
The synchronised clocks meant that once the operators had locked on, it would stay locked for a long time.
[1] https://www.nsa.gov/portals/75/documents/about/cryptologic-h...
Comment · 14 days ago
Also, just because the jury didn't think there was enough evidence to convict her of defrauding patients (beyond reasonable doubt), doesn't mean she was innocent.
Comment · 15 days ago
And so many things are broken in software too.
It was in development for a long time at a critical point in history. It seems to have started off as a software-first project (or possibly even software-only), then switched to hardware-first near the end of development. And not every effect was implemented in the hardware renderers.
Half-Life has a lot of grid textures that really need bilinear filtering and mipmapping to look decent, and they look even better with anisotropic filtering.
Many other games that released a little later (like Decent III) actually fully removed their software renderers before release because games needed to be hardware-only if they actually wanted to compete on visual quality.
Comment · 20 days ago
Since webp is little more than a vp8 iframe, and most SoCs already have a hardware vp8 video decoder, the additional hardware cost to decode webp is zero. Just takes a bit of firmware development effort.
And while hardware image decoders might be dubious, hardware video decoders are very much worth it.
Comment · 1 month ago
> (preferably integer) workloads like media encoding
Media encoding is actually an FPU workload, and a pretty brutal one at that.
Media encoding might not use much floating point arithmetic, but it does use massive amounts of packed integer SIMD. And all SIMD instructions (both integer and floating) execute on the shared FPU, not the integer unit. It's only scalar integer instructions that execute on the integer unit.
Which leads me to believe that Bulldozer's shared FPU is not a bottleneck at all. Most evidence seems to point to the shared frontend being the primary bottleneck (which is why steamroller puts some effort into duplicating the instruction decoding, for some pretty large IPC wins)
Comment · 1 month ago
Part of the reason we didn't see much in the way of YoY improvements for Bulldozer, is that AMD almost immediately abandoned it and threw resources at Zen after it launched.
Steamroller did see 30% IPC improvements over Bulldozer (all the design work would have been done before they switched to Zen), but AMD canceled the full FX version, and only ever shipped the APU version of Steamroller (with only 2 modules, aka 4 threads).
If they had shipped a Steamroller FX cpu, the generational improvements would have looked similar to many of the generational improvements that Zen received... but didn't really matter as Bulldozer started so far behind.
Comment · 1 month ago
The disagreement had been going on for years (at least since Google launched android, perhaps before that), Google and Sun had been in “negotiations” that were publicly documented as going nowhere. All that had happened is Google implemented more “workarounds” to use less of Sun’s IP.
I actually remember media speculating that Sun didn’t want to take the next step and actually file a lawsuit, because they didn’t have enough resources to go up against Google in court.
Then Oracle bought Sun, and suddenly the unproductive negotiations transformed into a lawsuit.
Comment · 1 month ago
My memory is that Oracle bought Sun for the Java lawsuit, not Java itself.
They had SMT, but unlike every other implementation of SMT I’m aware of, memory stalls on one thread would stall both threads… which kind of defeats the primary purpose of SMT.
At least with the PS3’s Cell, the SPUs were designed to be esoteric on purpose. It seems like Xenon kind of just ended up being esoteric by accident. (Or maybe they ended up like that because Microsoft were cheating off Sony’s homework)