I guess not without a minimum bound on the communication speed.
If you have a way to reliably transmit N bits in time T using P photons, you can transmit N+1 bits in time 2 * T using also P photons. What you would do to transmit X0,X1,...Xn is:
- During the first time slot of duration T, transmit X1,... Xn if X0 = 0 and 0 otherwise (assuming absence of photons is one of the symbols, which we can label 0)
- During the second time slot of duration T, transmit 0 if X0=0 and X1,... Xn otherwise
This only uses P photons to transmit one more bit, but it takes twice as long. So if you're allowed to take all the time that you want to transmit, and have really good clocks, I guess that theoretically this is unbounded.
There’s too much noise in the signal, and it’s also a skill gradient that I have been climbing for years. I don’t have enough samples to compare, and the samples don’t share enough similar context anymore.
If covid was a bioweapon, it was a very well-planned one.
I've noticed this with bullet chess, although not with reference to COVID specifically. My rating (such as it is) is extremely sensitive to mental health issues.
Says you'll ban spam. Unwanted commercial solicitation is free speech.
Says you'll ban incitement to violence and harassment. That is also free speech.
All that "free speech" means is that the government can't take a priori action to prevent it from happening. But there can be consequences.
All the popular platforms are free in that sense already. You will just have a boundary somewhere else for what you consider worthy of consequences.
Which is fine. I don't actually believe anyone enjoys a completely unpoliced platform. But maybe don't be so quick in saying you'll give a voice to the deplatformed, when you're a platform yourself and will ban people too for not adhering to your own speech police.
Even if you hate FIRE for defending the civil rights of people you hate, the article is succinct and contains links to the ca ten most relevant high level court cases.
Countryside roads that normally get very little traffic can quickly get clogged. If you're prepared to sit in your car for a few hours you're good though.
Also no need for glasses during totality. Before totality, you can look at the shape of shadows through a piece of paper with a whole punched in it.
> Countryside roads that normally get very little traffic can quickly get clogged.
Truth. I have a piece of land way out in the sticks here in Mena, AR, and on the rare occasion, our little backroads get very clogged up (think hunting season mostly), though we are right in the path of totality for the eclipse, and the town is even having an "eclipse festival" building up to it.
I'm thankful my wife and I won't have to drive anywhere that day. We're going to hang out in the yard and view it in our little field. Keeping my fingers crossed for nice, clear skies that day. :)
We're going to De Queen (my father-in-law lives there so we have a place to stay) - should be interesting getting out of there. I'm hoping that we're helped by the fact that that corner of Arkansas isn't the "obvious" place for anybody to go. We may just end up staying Monday night but we have reasons to be back to our normal life on Tuesday...
Abstractions should really make it easier than what's described in the article. There's no reason that in 2024, after almost fifty+ years of computer science, we still have articles saying "hey, here's a common pitfall that will throw no errors or warnings at you, but will deadlock non-deterministically one time out of one billion".
The problem with what is described in the article is the race condition. If you hit the race on your one pass through this code, you're dead.
But there are other conditions whether you know you will repeatedly pass through the code, and the race doesn't matter.
So the language/programming model has abstractions that can be used successfully for the latter. This has the unfortunate side effect of them also being capable of being used to create bugs in the former.
If you want a real world example of this sort of thing, consider a single-reader/single-write circular buffer/queue. You don't need any sort of interlock between the read ptr/index and the write ptr/index for this sort of data structure because if they mis-ordered (ie. the writer has added more data but not yet updated the write ptr), the worst that can happen is that the reader thinks there is less data in the buffer to read than there actually is.
However, that analysis relies on the model that the reader and writer are periodically checking the data structure. If instead they are both doing a single write and a single read, this same design will lead to loss of data flow between them. To ensure this doesn't happen, you need a mutex that they both share.
So is the right thing to do to require any such shared data to be protected by a mutex? Well, if you're only goal is to prevent data races, then sure. But if you also care about e.g. realtime behavior, then absolutely not.
This is just one example. There are many more cases where in case A you don't want or need synchronization primitives and in case B you absolutely do.
I'm familiar with the trade-off. But I disagree that there's a choice to make between safe and powerful. It is possible to make safe behaviors by default, while leaving the door open for more advanced behaviors. I guess code linters can help as crutches. But the right abstractions too.
It's the motivating example for languages like C++ in the first place (over assembly): type safety, easier reasoning about control flow, etc.
Note how the case here is very simple - waiting on a variable to change - but advice just boils down to "be more careful" instead of "here's the foolproof way to do this". You can only ask a programmer to watch out for so many things, and C++ has way too many of these things.
I would agree with GP comment: in the particular case described in the article using channels instead of lower-level primitives would solve the problem.
E.g. when workers need to be stopped you close the channel sender, and receiver returns appropriate result to all wait calls.
This objection of yours was directly addressed by the comment I'm trying to support.
E.g. yes, it is important to know the low-level details, but also the abstraction chosen is just not fit for the purpose. And it's partially fault of C++ because channels are not in the standard library.
I have obtained an email from GM stating that if I am an OnStar Smart Driver subscriber, I cannot opt out of my data being shared. I believe this violates at least California privacy regulations, probably some other states, which mandate opt outs. I seriously want to rip the modem out of my car.
The coda to the story is hilarious. CCPA apparently has an exemption (I'd say loophole) for the sale of personal information to consumer reporting agencies, as long as the use of that data is covered by the Fair Credit Reporting Act. So if FCRA allows it, CCPA says go right ahead!
"Racing the beam" — omg I know exactly what you mean. We used to set the beam to different color at the beginning and the end of our vsync'd routine to figure out how many scan lines worth of CPU time per frame we could afford to use. I remember the address $dff180 for this purpose (color palette 0, which would always show on the edges of the screen outside of the bitmapped area). We didn't have the Internet to teach us that trick either, all word of mouth! Didn't know there were people still trying to squeeze more out of that chipset nowadays.
I use the same trick today! I have some "benchmark" macros set up which forcibly override the background color when I want to see where in the frame my operations are taking place.
> Didn't know there were people still trying to squeeze more out of that chipset nowadays.
You will be amazed. The demoscene has gotten insanely good since around 2017. Here are some of my favorites that all run on a stock Amiga 500 (with the trapdoor memory):
Wow... Looking at the links on one of these, I see that the tooling has evolved a lot from the days of just text editing + assembly https://tbl.nu/2019/08/20/Tooling/
Wow. Thanks for posting these. Reminds me of 8080MPH / Area 5150.
I don't know enough about amiga chipset limitations to know which bits I should be impressed more by, but a doing this on a 68k @ 7mhz with 1MB RAM is impressive enough.
reply