Prompt injection in hardware! What could possibly go wrong?
116 karma · joined October 29, 2011
The distributed repos and "commit-then-push" metaphor might be due for a replacement since we're always online anyways and repos grow larger and larger. Perhaps using VFS where all files are always instantly available with copy-on-write semantics.
There are several players working on systems that work on thousands of commits per second scale, some based on Git and others not.
And it relates to Windows and Linux only, and using the TPM.
My guess is that unreliable TPMs made it risky to have this enabled by default.
In addition your favorite Linux distribution probably has it as from-source builds already.
For a container image you could try making one from Alpine or Wolfi.
The central bank controls how many bills are in circulation, and the central bank regularly expires old bills and coins.
They did not like the idea. They very much more like the idea of owning the customer and keeping the customer paying subscriptions.
I also know of a media outlet which incentivizes customer to go from credit card payment to automated bank transfers, since credit cards expire every x years but the bank transfer goes on forever.
You are paying for:
- A reproducible target. You know EXACTLY what code you are running. If you manage more than three installations this is the only way you can diagnose and fix whatever issues your installation has.
- Support. The very few times I used RHEL support I always got timely and thorough assistance. Even when chasing a hardware bug or issues with third party device drivers.
- Backwards and FORWARDS compatibility. Red Hat systematically backports kernel bug fixes and support for new hardware to old kernels. We ran 2.6 kernels on Intel hardware released long after the 2.6 series were EOL.
- Device drivers. No, not for your five dollar mouse, but for hardware that costs the same as a small SUV.
If you're avoiding RHEL due to cost, have a look at their SKU list and talk to your local sales org, they have a wide range of options.
(Not affiliated with Red Hat or IBM, but RHCE since 2004)
> "Kermit will send data over a communication channel that is only slightly better than a pair of tin cans connected with a wet string")
Then again, I was only using the free tier, so I guess I got what I paid for.
> The NTP protocol will synchronize correctly, regardless of era, as long as the system clock is set initially within 68 years (a half-era) of the correct time
- Both Playstation 5 and Xbox Series X use x86 processors.
- MacBook market share is around 10%, so the majority of new laptops are still x86.
- The majority of cloud compute instances are also x86.
But also Windows 10 backup pointing to a VMDK on the C: drive for recovering from blunders.
Oh, and tarsnap for the really important stuff.
For me it's got the best balance between features and simplicity.
Any more features and the battery (life or size) would be worse.
Sleep and step tracking is average, notifications are just right.
I'm hoping a reasonable replacement surfaces before it dies, and am still sad Fitbit destroyed this product, and won't be considering any of their products for that reason.
Jobs are configured by adding an entire GitHub organization. All repositories with corresponding branches, pull requests and tags are automatically discovered and built based on the existence of a Jenkinsfile.
Everything is built by slaves using Docker, either with Dockerfile or using builder images.
Job history and artifacts are purged after a few weeks, since everything of importance is deployed to Bintray or Docker repositories.
By keeping Jenkins constrained in this fashion, we have no performance issues.
Even from JSON or XML.
True, directly using that electric energy from wind or solar is definitely the best option.
However, that is not always possible, since there is no place to consume, transport or store that electric energy.
Furthermore, scrapping all ICE vehicles for BEVs is most likely the end goal. But replacing the worldwide fleet of vehicles will take decades.
HyTech seems to be on to something for these two scenarios.
If for instance you can capture some of the excess solar and wind energy in a metal hydride for some hours, weeks, or even months, you will on a larger scale reduce the load of the electric grid.
And if some of that Hydrogen can be burnt instead of Diesel, the car or truck in your driveway is both cleaner and less dependant on fossil fuels.
Git for Windows, and SourceTree for all serious Git work except interactive rebase.
For building, testing and packaging, Docker. This way I don't need to spend lots of time maintaining runtimes for all languages and environments. If things go weird I just factory reset the Docker installation.
I used to do choco and a lot of tools maintenance, but that is all history with Docker in the mix.
Service and operational costs are already lower on EVs than fossils, and that is unlikely to change significantly.
For example, with current gasoline and electricity costs in Norway, powering an EV costs 10% of what a fossil cost per kilometer.
So incentives might be necessary right now, but not for much longer.