treffer

Even RPI5s with the Broadcom BCM2712 which is super high volume is 16nm. If they manage to get 5nm in 2026 at low cost than that's the path to take the SOC crown.

This could even lead to RISC-V SOCs/SBCs at RPI power and price tag (yeah, still dreaming).

My rule of thumb is this: you need to touch a codebase _more_ to throw it away.

Tell that to whoever wants to rewrite. You will have to maintain the old application anyway (yes, this is a given, you are not getting an exemption for security holes) and you will have to de-risk the project by providing value (== release early, release often, continuously switch parts over - which requires work on the legacy side, too).

If someone wants to do a big bang rewrite then you need to fight for the importance to touch the "legacy" codebase. That is the actual reason why people are so religious about their rewrite.

Other than that: same thing, ~20 years and nothing good comes out of big bang rewrites and releases.

I've definitely seen this. That's how IPv4 connectivity became an enterprise/business line feature on some ISPs.

A neglected detail about CGNAT is that it has lower the quality of IPv4 connectivity. Higher latency + more connectivity issues.

So if you offer a service then you should offer it on ipv6 due to that.

That's a really slow transition though. So I wouldn't expect this to kill off IPv4 any time soon (say 10y), but longterm it's been the trajectory already.

E.g. Pebble was sold to Fitbit due to insolvency. And the cloud services continued to run for a year.

Bankruptcy does not necessarily mean everything is gone. Deleting everything is actually the _worst_ outcome as it destroys value.

Not having any promise means it will pretty sure be gone. Having a support promise increases the chances of future support, even in case of bankruptcy.

On the other hand "emulator" is usually some hardware emulation. Whereas the flas player was basically a runtime / vm for Flash files. And Ruffle is a different runtime implementation.

It's like saying any non-oracle Java is a "Java emulator".

Scummvm for example follows that line of thought: "ScummVM is a complete rewrite of these games' executables and is not an emulator."

Anyway, given what Ruffle says I would probably side with them....

GDPR is about consent, not cookies, storage or anything. If you track a user then you need consents. Nothing about GDPR is tied to cookies. They are just one way to generate and keep PII (a tracking ID).

Now if the UTM only identifies the source (user coming from X, FB, ...) and does not identify or reveal the user then you are probably fine. It should even be fine as a cookie, although there have been talks about storing on a users device without consent. Not sure about the current exact legal status, so you might want to set it to never persist the browser close.

It might get a bit more complicated at sign up. You probably would want to disclose that you track and keep this information. But at this point GDPR is active for sure as you have a somehow identifiable user.

Most of these old ones seem to be listed in Germany and Paris.

Due to all of that I mostly ignored the 6GHz wifi stuff.... So interesting to hear it's working for you. That's the first time I hear someone from Europe say it's working for them.

No outdoor use unless power is capped massively

But I can highly recommend to get Wifi 6 on the 2.4 GHz Band, too. I've finally gotten usable 2.4GHz again as that band was stuck on Wifi 4 (Wifi 5 (ac) was a 5Ghz improvement only).

That's my way to manage a few openwrt devices

But sometimes that's not worth the hassle. E.g. I disabled locks while my car was running.

The tradeoff is IMHO well worth it as I immediately take the phone from the car should I leave. So the overall risk is minimal. Yet should it ever distract me then that's a big issue.

And not being reachable was also not an option given family circumstances at that time.

It's just a risk vs. benefit tradeoff. And that's a very personal judgment call.

I was thinking of ROI for reading code. Regularly having a one line issue in a 100 LOC file is very different from a two line issue in a 10'000 LOC file.

And yes, tests need to be excluded, of course. But looks like that's done?

Or perhaps a LOC changed / file LOC based distribution. That would be how buggy each file is, with a $$$ tag.

If money is a bad way of keeping value (bad banks! Inflation! Money printing!....) then holding a negative amount (debt) and putting it into other parts of your portfolio is a good idea.

A really a basic idea, with a solid mathematical foundation. I can highly recommend the first week of financial markets on coursera if you want to see a not so controversial introduction to this concept.

The only problem is that it adds risk (swings could become larger than your net worth, which can mean bankruptcy)

IANAL, but worked through implementations that can work without banner consent.

I don't want to imply that it is easy or anything. It's pretty annoying, especially as the purpose of that data needs to be tightly tracked. But it is totally doable.

You can provide whatever the user wants to do. Recommendations? Sure. If you want them. The required data collection is then just.... Required. It is tied to this purpose though and can't be used e.g. for ads.

But it is not OK to collect everything about the user so you can charge more for ads or to sell ("exchange") that information. Which is in 99% of cases the reason for these banners.

It's been the cheapest source of energy worldwide, at ~4 cents iirc, and falling. For several years now.

The question is no longer what to pick based on cost per watt: it's solar.

Cost per Watt is relevant as a historical curve.

Efficiency on the other hand provides an outlook. We can get 4x more efficient solar cells (theoretically). We are still getting manufacturing improvements and scaling effects. I would expect solar to break through the 1 cent per Watt barrier based on that.

So a rerun of the program should only need to load ~8GB if the filesystem caching is somewhat loop/scan resistant.

My first thought was "probably the math is wrong", but looks like it adds up to something reasonable - especially as all numbers are rather vague / rounded (e.g. let it be 12s) and the number was just high, not absolute maximum.

> In beamer, the default sizes of the fonts are chosen in a way that makes it difficult to fit “too much” onto a slide.

Many of the ideas apply outside of latex/beamer. It's one of the better free documents about the technical aspects of slides. At least if the presentation is still driven by content on the slides, but that decision is a whole different story.

It's just that first consumption age went down and audience widened.

Overall I think the internet has become safer, especially through the required handling of content complaints. It's just that the usage went into a direction that needs more safeguards.

Q4 should be well below the 32GB (2x 16GB).

I am wondering if the same implementation could be done for RAM to CPU, too. Those are said to be data transfer limited, so minimizing the RAM to CPU cache transfer should help there, too?

> systemd is written to deliberately (ab)use every single non-portable extension under the sun

I think this should be split into 2 parts. Linux specific kernel features and userspace extensions (GNU vs. POSIX).

Using linux specific kernel features (like cgroups) is good for a linux system. E.g. a common issue with sshd used to be that under high load it would become slow and problematic to log in. Systemd configures the system such that this becomes less likely to happen.

For userspace extensions I would have hoped that systemd would see it as a net positive to build upon a smaller set of tools and features, but the page seems to indicate otherwise. Does anyone know what happened on that front?

But why do I say 20% reduction in work?

Bugfixes and features that get fixed/finished on Fridays will ship 3 days later. Do your average lead time increases by >0.5 days. This impacts anyone relying on you, too. So if this happens org wide then features and projects may ship days to weeks later.

Oh and what are you doing on Fridays then? Less relevant work? If you stick with priorities then you are just queuing up more changes for Mondays, leading to nice higher risk deploy Monday. You simply can't gain stability with skipped Friday deploys without changing / ignoring work priorities for Fridays.

So yes, this should be comparable to such a reduction.

Oh, and Friday deploys ruin your weekend? That means you have really high detection and mitigation time. With 1h detection time and 2h recovery I could still with low risk deploy Fridays, 5PM, wait 1h and enjoy a weekend after wrapping up my work.

I have always shipped on Fridays. It never ruined my weekend. Even though I did have a few fun screwups (which sometimes required help from my coworkers).

Especially combined with: urgency (matter of life & death), referenceng laws/penalty if not handled (quickly), reference to kaws/penalties if disclosed.

Now some poor lawyer has to figure out what to do.

Now just heavily increase what you I.agine the scale to be. Those revealed cases are just the tip of the iceberg.

As much as I would like to blame Verizon or any other entity: I think the key point is that the way these warrants get handled is totally unsuitable for the internet age.

Forgery is usually a crime. So sending a warrant (via paper mail) through a country is sorta safe as you can start chasing the criminals, especially through return addresses.

This all changes on the internet. Someone in a different country or a mostly anonymous person can forge and send these warrents at close to zero costs. Enough police stations got hacked to get realistic templates (and sometimes even direct e-mail access). The whole cost/benefit/risk relation shifted in favor of the attacker.

And it doesn't help that most countries want to fast-track these requests even more.

At the moment I even envy the people who can't scan without ink. I just get a "how about creating an online account for local scanning" and "how about using your phones camera instead?". That's my scanning experience. A raspberry pi over USB does some scanning, but it's a bad UX instead.

I also regularly can't print, an odd error pops up that goes away if you print once via USB. I have a cups airprint server on a raspberry pi just for that. So apparently IPP over ethernet vs. IPP over usb causes a 100% reliable error until a different transport medium is used.

So yes, I notice these changes. And it changed my mind about HP. It was a smooth printing experience when we bought the device. And this is not an aging issue, it's actively crippling a device I paid for.

It would head well into advanced user/password schemes.

The problem is that even advanced mechanism like a SCRAM based authentication with additional 2fa are rather simple to grasp & implement, but really hard to get right / secure.

A lot of the evolution is rather an evolution of attacks and issues, leading to new schemes. OWASP is thus pretty relevant, too.