That’s a complicated question. The Wonderwerk Cave in South Africa where we found the first evidence of controlled fire also contained burned plant remains and bones, which could be interpreted as evidence of cooking. There were also burned fish remains found at the Gesher Benot Ya’aqov site in Israel, dated to about 780 kYA, which could also be interpreted as evidence of cooking.
By far the strongest evidence is the Qesem Cave in Israel, which had a central hearth and so many burned animal remains that it couldn’t have been accidental. Unfortunately the dating on that is controversial and the error bar is huge at 300 +- 100 kYA (200,000-400,000 years ago).
i guess the point of having a tag in the shape of a card is to prevent a thief from throwing the obvious airtag away, the card tag may look like an ordinary bank card and kept in the wallet longer
Well, if your manager can see your employee file (which they can.... certainly in Worlday) they will know your birthday. Oddly, at my employer, celebration of individual birthdays is discouraged, I have heard it is because it might make someone feel uncomfortable being called out for aging. As someone who is probably in the oldest 1% of the company... I find that amusingly curious. Birthdays are a good excuse for a team celebration, and that is almost always good team bonding.
Mostly agree, but we don’t have to give up the benefits of direct digital tabulation for quick results. I would like a paper audit trail. Print my ballot-as-cast for on a paper roll that scrolls by under a window. I can verify it before leaving the voting booth. Recounts and challenges can be a computer scan of the paper roll. None of this is hard. Costs a bit more, but buys trust in the system.
This is the system used in the majority of the United States. Direct-recording electronic voting systems were never that common, briefly peaked after the Help America Vote Act as the least expensive option to meet accessibility requirements, and have become less common since then as many election administrators have switched to either prectinct tabulators or direct-recording with voter-verified paper audit trail.
In the 2026 election, only 1.3% of voters were registered in jurisdictions that use direct-recording electronic machines without a voter verifiable paper audit trail (https://verifiedvoting.org/verifier/#mode/navigate/map/voteE...). 67.8% of voters are registered in precincts that primarily use hand-marked ballots, and the balance mostly use BMDs to generate premarked ballots.
You don't necessarily need any sort of electronic counting for quick results. Federal elections in Australia are usually called late on the voting day and I imagine the same is true for other countries that are paper-only.
Votes close at 10pm. Might be a few stragglers left in the queue, so call it 10:15pm. (Exit poll results are embargoed until 10pm.)
Ballot boxes are transferred from individual polling station to the location of the count. The postal votes have been pre-checked (but the actual ballot envelope has not been opened or counted) and are there to be counted alongside the ballots from the polling stations.
Then a small army of vote counters go through the ballots and count them and stack together ballots by vote. There are observers - both independent and appointed by the candidates. The returning officer counts the batches up, adjudicates any unclear or challenged ballot, then declares the result.
The early results come out usually about 1 or 2. The bulk of the results come out about 4 or 5. Some constituencies might take a bit longer - it's a lot less effort to get ballot boxes a mile or two down the road in a city centre constituency than getting them from Scottish islands etc. - but it'll be clear who has the majority by 6 or 7 the next day.
I can appreciate that the US is significantly larger than the UK, but pencil-and-paper voting with prompt manual counts is eminently possible.
That's how it works in Cook County and a lot of other places: it's touchscreen voting, using "ballot marking devices", which produce a paper ballot you hand to an EJ to submit.
Some paper jurisdictions have this, essentially. E.g., where I live: the ballot is a paper ballot. You vote by filling in a circle/bubble. (If you're familiar with a "scantron" … it's that.)
It looks like a paper document intended for a human, and it certainly can be. A machine can also read it. (And does, prior to it being cast: the ballot is deposited into what honestly looks like a trashcan whose lid is a machine. It could presumably keep a tally, though IDK if it does. It does seem to validate the ballot, as it has false-negative rejected me before.)
But now the "paper trail" is exactly what I submit; it's not a copy that I need to verify is actually a copy, what is submitted it my vote, directly.
> I would like a paper audit trail. Print my ballot-as-cast for on a paper roll that scrolls by under a window. I can verify it before leaving the voting booth.
Why should you be forced to trust that what you're shown is also what was being counted? The paper record should be the actual ballot itself, with your actual vote on it.
> If there is one thing about Windows that is really good, it is its kernel and driver architecture,
Woah, back up a bit. In the article, it looks like the blue screen is a 0x0 (iopr) exception, likely a wild jump into the weeds. But back in the day, the majority of blue screens were 0xE exceptions -- page fault in the kernel. Why? Buggy driver that didn't wire down a page and it got swapped out from under the driver. Not under Microsofts direct control... BUT... they had a great example in OS/2. In WinNT, there are 2 security rings, kernel and user space. But x86 supports 4 rings. OS/2 used ring 1 for drivers, so that the kernel could both blame the correct driver and also stay alive. So simple. (Of course, it means it is hard to port to hardware with only 2 security rings.) WinNT drivers are not things of beauty. The dev experience is cranky, and validation is a nightmare -- and the lowest bidding Asian contractor that is writing your driver for your el-cheapo peripheral rarely signs up for that nightmare.
> WinNT drivers are not things of beauty. The dev experience is cranky, and validation is a nightmare
I think one could say the same for any platform; in general, developing drivers is just difficult, full stop. That driver quality for peripherals can be bad is not the fault of the platform. I'm sure I could find dodgy drivers in the Linux tree that were merged in only because 'shrug it makes PineappleCorp's device work, who cares if it is littered with UB'.
Well, these days it seems Linux drivers get enough eye-balls on them that anything meaningful is going to get looked at. Sure, I expect there are some low usage drivers in the repo that just haven't had enough mileage. At least with Linux I can see the driver code. (The second day at my current job, somebody pointed me at a bug with an obscure symptom. A quick check of a log file showed a 0xE exception. A couple hours later I posted a link to the bug in source. Somehow, the universe decided to give me a bug I had seen many times before to get my reputation off to a good start -- it's better to be lucky than smart.)
At the dayjob we have lots of sporadic problems with USB drivers of Linux in our fleet of embedded devices (RPi). I had a lot of problems with USB-C and Thunderbolt docks in last 5 years. If USB doesn't get enough eyes to not crash/freeze systems entirely, I don't know what else would get. Monolithic kernel design should have belonged to past but we don't get nice things.
There are performance penalties for moving drivers out of the kernel/ring 0. For some things, that matters (network, graphics), for others it doesn't, like printers.
And Microsoft has made the least stable of the drivers a recoverable fault, at least.
Legal would probably tell you to purge anything older than 180 days, unless there is active discovery for a lawsuit, in which case retain until end of law suit. Retention is a legal policy issue, which may vary from company to company, and change when a new GC onboards. That should be driving the technical requirements.
Or… someone seeing a bunch of commercial flights over the Caribbean getting cancelled. Could be anyone from airline ops to frustrated travelers stranded in Boston.
I guess... but I still think first thought would be just some more bombing. It's a big step to go from bombing boats, a dock, arresting and extraditing a foreign leader in the middle of the night.
The way I've heard it is: Being a microwave engineer is the easiest job in world. You basically only do two things, design oscillators and design amplifiers. What's the worst thing that can happen to an amplifier? It oscillates! And what's the worst thing that can happen to an oscillator? It won't start, but it's usually still a pretty good amplifier. Win-win!
It is important to remember that IEEE 754 is, in practice, aspirational. It is very complex and nobody gets it 100% correct. There are so many end cases around the sticky bit, quiet vs. signaling NaNs, etc, that a processor that gets it 100% correct for every special case simply does not exist.
One of the most important things that IEEE 754 mandates is gradual underflow (denormals) in the smallest binate. Otherwise you have a giant non-monotonic jump between the smallest normalizable float and zero. Which plays havoc with the stability of numerical algorithms.
Sorry, no. IEEE 754 is correctly implemented in pretty much all modern hardware [1], save for the fact that optional operations (e.g., the suggested transcendental operations) are not implemented.
The problem you run into is that the compiler generally does not implement the IEEE 754 model fully strictly, especially under default flags--you have to opt into strict IEEE 754 conformance, and even there, I'd be wary of the potential for bugs. (Hence one of the things I'm working on, quite slowly, is a special custom compiler that is designed to have 100% predictable assembly output for floating-point operations so that I can test some floating-point implementation things without having to worry about pesky optimizations interfering with me).
[1] The biggest stumbling block is denormal support: a lot of processors opted to support denormals only by trapping on it and having an OS-level routine to fix up the output. That said, both AMD and Apple have figured out how to support denormals in hardware with no performance penalty (Intel has some way to go), and from what I can tell, even most GPUs have given up and added full denormal support as well.
At those power levels they would have to use some kind of highly error-corrected modulation and coding scheme to provide enough coding gain to overcome the path loss. I agree they are pretty optimistic, but until they detail their modulation scheme, it's hard to tell.
A few years ago I was experimenting with 900 MHz LoRa for a work project -- we had need to communicate a very small data payload from inside elevator cabs, with forgiving latency requirements. So we took a LoRa board to a hotel building 2 city blocks away from our lab and cranked the coding gain up to the max, which gave us about a 1 byte payload every second. Perfectly sufficient for our application. Astoundingly, we had great copy in our lab even when the doors of the elevator cab were closed, inside a building 2 blocks away. I can't remember the power level, 500mW I think, but I may be wrong.
reply