Sure but a system that breaks if it doesn't get exactly 86,400,000 millisecond scale scheduled events in a day has already been driving your SRE team insane.
HN user
oconnore
eric@oco.nnor.org
I don't understand why people are so negative about IPv6. I have done essentially zero home networking work and I just ran this successfully. It just works!
``` > ping6 google.com PING6(56=40+8+8 bytes) 2605:59c0:236f:3a08:7883:9d04:c26d:5fa1 --> 2607:f8b0:4005:806::200e 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=0 hlim=117 time=22.262 ms 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=1 hlim=117 time=26.124 ms 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=2 hlim=117 time=26.807 ms ^C --- google.com ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 22.262/25.064/26.807/2.001 ms ```
Why would you be running sudo in production? A production environment should usually be setup up properly with explicit roles and normal access control.
Sudo is kind of a UX tool for user sessions where the user fundamentally can do things that require admin/root privileges but they don't trust themselves not to fat finger things so we add some friction. That friction is not really a security layer, it's a UX layer against fat fingering.
I know there is more to sudo if you really go deep on it, but the above is what 99+% of users are doing with it. If you're using sudo as a sort of framework for building setuid-like tooling, then this does not apply to you.
Can you share how the scripts work? That seems to be the most interesting part, but is omitted from the article. The only technical details are UART + an opto-coupler.
Both devices run custom scripts designed to handle data transmission reliably rather than quickly. This approach limits throughput, but reliability is paramount for critical monitoring, where losing data is unacceptable. The scripts are finely tuned to ensure that every log entry is transmitted securely without risk of cross-contamination between networks.
I'm not sure which dimensions you're talking about, but in terms of bed size the F-150 has been very consistent over the years (although I think Crew Cabs — although they always existed — have become more popular). The Ranger still cannot fit a full sized sheet of plywood flat in the bed.
Quick research: the new Ranger's bed size has only increased 0.9" (width) relative to the 1990 version. Bed length seems to be the same.
I was considering getting a Rivian and decided that in fact I would probably not allow the 24 year old dude at my local construction supply co to use a skid steer to drop a load of gravel into the bed of my $75k+ electric vehicle.
So instead I got a used Ford F150 (gas) and when the skid steer guy drops gravel into the bed I feel fine.
Why do you do this?
The only disappointing aspect of the Iocaine maze is that it is not a literal maze. There should be a narrow, treacherous path through the interconnected web of content that lets you finally escape after many false starts.
I guess you had a bad experience, but this hasn’t been an issue for me using it for many years now.
If this is a concern, pass your UUIDv7 ID through an ECB block cipher with a 0 IV. 128 bit UUID, 128 bit AES block. Easy, near zero overhead way to scramble and unscramble IDs as they go in/out of your application.
There is no need to put the privacy preserving ID in a database index when you can calculate the mapping on the fly
This package also seems to just have a misbehaving github action that is in a loop.
This is a lot of fuss when you can get a batch update to stay within a few minutes of latency. You only have this problem if you are very insistent on both (1) very near real-time, and (2) Iceberg. And you can't go down this path if you require transactional queries.
I think most people who need very near real-time queries also tend to need them to be transactional. The use case where you can accept inconsistent reads but something will break if you're 3 minutes out of date is very rare.
Wikipedia is based in San Francisco. Why can't they just tell the UK to pound sand?
Perhaps change the link to the original NASA JPL post: https://www.jpl.nasa.gov/news/voyager-2-illuminates-boundary...
No one is being replaced 1:1, but everyone is going to be downsizing (and that’s mostly the same thing).
You need a lot fewer managers if your team is 5-20% what it needed to be a few years ago.
What's wrong with just eating a bit
For one thing you won't get many likes, subscribes, retweets, or what have you.
256 bit symmetric cryptography keys are a bit like picking one atom in the universe (10^80 atoms, or 100000000000000000000000000000000000000000000000000000000000000000000000000000000). Your opponent would have to test half of the atoms in the universe to have a reasonable chance of getting the right key.
That's generally understood to be not feasible.
Could someone like the NSA with limitless resources do it? Quite probably, sure.
If you're not worried about a fairly well-resourced government agency uncovering whatever network activity you believe needs to be anonymized, why would you be using Tor at all?
I thought this would be a different proposal.
But on the topic of verified HTTP: something that I think you could do that would be pretty neat would be to allow first party assets to be offline-signed and then delivered over unencrypted HTTP (port 80).
This would mean that you could ship secure applications over HTTP (port 80) with guaranteed integrity even assuming that the server is or will become compromised.
As I understand it, the earliest they could actually strike would be 80 days from today, as per the Taft-Hartley act, putting the strike on November 29 (after the election).
Something seems broken when a group is paid relatively fair wages (https://www.levels.fyi/companies/the-new-york-times-company/...), works 35 hours a week before overtime, and is talking about going on a strike. I don't think that fits with the original purpose of unions.
I am excited and optimistic that we appear to be applying economic principles to housing! Now that we're getting rid of centralized price controls / collusion, next can we do supply/demand?
My first thought was, “oh, I used to do this when I wrote Common Lisp, it’s funny someone rediscovered that technique in <rust/typescript/java/whatever>”.
But no, just more lispers.
It seems like the chemistry has some interesting trade-offs.
https://www.mitsubishicritical.com/resources/blog/the-runawa...
https://www.linkedin.com/pulse/which-better-nickel-manganese...
NMC does have an increased fire and thermal runaway risk
The USA has put regulations and restrictions in place to make sure certain sources of Cobalt and other minerals are not used in future supplies and designs. Estimates show that there will be a Cobalt shortage by 2028, which has been quickened by the increased use of Cobalt in electric vehicles and battery energy storage designs
NMC has increased energy density with a cycle life span that is geared towards a reduced number of cycles per year.
The full charge and discharge cycle of the LFP battery will only decay to 80% of the original after the number of full charge and discharge cycles is greater than 3500 times. … The charge-discharge cycle life of NMC battery is about 1000 times.
It occurs to me that in year 2000, we had already invented Kerberos, Merkle trees, AES, and McEliece. Kerberos for one is built on symmetric cryptography, and is as far as I'm aware not vulnerable to the sorts of attacks that make RSA, Diffie-Hellman, and EC solve-able by a sufficiently advanced quantum computer.
How do you define your bet such that you don't just win by default?
Sure you can, but it's rare to see a GUI app built keyboard first and specifically optimized for the productivity of power users. The list of apps that do this successfully is a tiny fraction of the total.
- Excel
- 3D modeling tools
- Adobe Creative apps
- Programming IDEs
- ?
Also, if you are focused on that metric: the productivity of the power user, then in many cases adopting a more modern GUI framework will not necessarily make it easier to achieve that goal (and in some cases may make it harder).
Legacy apps never die
I think it's a mistake to frame this as legacy vs. new. There are real benefits to the approach taken by these TUI applications and it would behoove modern app designers to learn from them.
It's perhaps the case that those coffee shops will someday adopt a TUI once they reach a level of sophistication. As an example: I believe Starbucks uses a TUI for order processing.
Case 1 is moot, case 2 would be prevented by properly implemented HTTPS.
That's not true. It's significantly easier to ensure the security of an offline signing key than it is to ensure that an arbitrary HTTPS server avoids ever becoming compromised.
HTTPS is irrelevant here. You can send incorrect headers in either.
I think you misunderstand their suggestion. If you only gave service providers access to encrypted data (i.e. End-to-end encryption), then neither the service provider nor the leaker would be able to decrypt.
Whether or not that is a generally viable or desirable suggestion is a different question, but it is possible as demonstrated by Signal, Apple, etc.
Is it getting worse? This is the first outage I remember in a while.