mentions 3 three alternative interpretations for GRB 250702B:
1. Ultralong Collapsars: These stellar-engine models can explain long durations but struggle to account for the specific timing of this event. Specifically, they cannot easily produce a 12-hour gradual rise in X-rays followed by a multi-hour peak, as the jet would have to fight through a massive progenitor star while its power is still very low.
2. White Dwarf (WD) Tidal Disruptions: While an Intermediate Mass Black Hole (IMBH) disrupting a White Dwarf could theoretically provide the necessary gravity, the numbers do not add up for this specific burst. The timing between flares is too long for a WD scenario, and the total energy required would demand an unrealistically narrow jet. When physical constraints like detonation are factored in, this model is considered highly unlikely.
3. Micro-TDEs (Main Sequence star by a stellar-mass BH/NS): This is considered a competitive alternative that can explain the burst's sub-second variability and long duration. However, it faces two main issues: current afterglow data suggests the surrounding gas density matches an IMBH environment better than a micro-TDE environment, and the burst’s extreme energy would require very high jet efficiency or a very narrow beam.
Sorry, but can someone explain to me why Flash failed? Was it because Apple killed it, or other reasons? Because not open source? Too heavy? I never really got the story, or only got bits and pieces. I know a lot of people liked Flash.
I had my handyman build one of these in front of our house. Also, I make a hobby of biking around to circulate books between different little free libraries in my extended neighborhood. I've found some amazing books over the years, things that were very different from my typical prior experience of books. I like this aspect, that it can be eye opening. Each little free library has it's own style of books. Some are better at handling magazines. Some see a lot of book movement, some much less. These factors influence how I move books around from one to another.
Suggestions on building a little free library:
1) By far the number one priority: Waterproof. If it's not waterproof, in my opinion you're actually doing a disservice to the community, rather than a service. And have an angled roof for proper drainage.
2) Don't make it too deep. Definitely not more than 18 inches. Probably 15 inches is a good depth.
3) If you can, make two levels: One level for tall books, another level for short books.
4) Don't make it too tiny, because then it's hard to get books in and out of.
5) A good solid stand so it doesn't fall over.
6) A good latch that will resist wind. Magnetic is good. I also like to have a magnet plus a hook that can be used for backup. Also with time it's nice to have the second option in case the shape changes a little and the magnet doesn't work.
7) You might try making a mockup out of cardboard so you can see the physical size and get a sense of how many books will fit.
8) Not a building tip, but: Try to arrange the books to look nice. If you have few books you can face some of them to attract attention.
Great points - a Little Library near me has become more of a dumping ground than it used to be because when they re-did it, they replaced the clear plastic window with a frosted/corrugated plastic (you can't see what's in it without opening the door), and they replaced the hook latch with a chain one that lets rain get in.
Magnus is just so tenacious. From a lost position he snatched a victory. Take a look at the five hour mark (plus or minus) for the crucial moments of the key game: https://www.youtube.com/watch?v=s6ey5Up4S7w
A read-it-later app. Pocket, you had one job. Just one job. And for a while that was my killer app on mobile. But, as we see, the enshitification of the web continues.
"What began as a read-it-later app evolved into something much bigger. After Mozilla acquired Pocket in 2017, we invested in building our content curation and recommendation capabilities so people everywhere can discover and access high quality web content. While Pocket is shutting down, we will continue to invest in this promise—through the New Tab experience, our email newsletter, and more."
Here's an idea: Compensate any on-call work received during off hours at 10X the normal hourly rate. E.g., if my salary is $150K per year, then my hourly pay rate is about $75 per hour, so compensate my on call work at a rate of $750 per hour. Thus if I get a call at 10pm, log in to my laptop and work for 30 minutes to resolve the issue to a satisfactory level, then I pocket $375. That puts a financial incentive on companies to structure their on call protocols so that only the most important calls are handled. And I can envision variations on this theme. Different sorts of on-call disasters could offer bids for how much they're worth to fix based on some automated rubrick, and anyone on the ENG team could pick these up on a first-come, first-serve basis. Or various combinations of the above for a guaranteed backup person. But the companies should offer enough incentive to make it worthwhile. And this is in the companies' own best interest. To maintain a workforce that can think clearly during the normal work, to have a good reputation in the industry, to get good reviews on Glassdoor, etc.
Have a minimum of say, 60 minutes, and if that is exceeded, the issue gets escalated or deferred. If deferred, presumably to the next day shift, the cost is limited. If escalated, the second person must also defend the time spent. If management still doesn't trust their workers to be honest, then the company has other issues that tweaking on-call will not solve.
Many systems that pay hourly for task-based work like this deal with this problem by instituting a minimum number of hours of pay per-instance, which is usually higher than the expected time it takes to complete a typical quick task.
That way, by taking longer on any but the hardest issues, you are instead removing your ability to make more money on other, faster issues.
If you call out a master electrician to flip a circuit breaker, they are going to charge you a lot more money than for the half second it took to flip the switch.
Also, if the reason they have to come flip that switch is that they screwed up the job they did earlier that week, you don't get charged at all.
This thread is full of people acting like highly experienced trade workers are idiots who have never thought of how hourly work might be gamed for more money. All of this has been long since solved by the industries that actually operate this way.
> Many systems that pay hourly for task-based work like this deal with this problem by instituting a minimum number of hours of pay per-instance, which is usually higher than the expected time it takes to complete a typical quick task.
That's how it works for the occasional on-the-side server/printer tech jobs I occasionally take (long story short: I took a temp IT job years ago, resigned to go somewhere else, but the company never took me off their payroll so I get the occasional call to go install some number of printers or some number of servers/switches/etc. for some customer of HP or Dell, respectively). The usual rates are pretty abysmal for someone of my experience and skill level, but the 4-hour minimum means that if I can bang out one of these jobs in an hour or less I'm making more per-hour than at my day job. Nice bit of occasional money to blow on craps or penny stocks or shitcoins or whatever, and it keeps my fingers on various industry pulses.
> If on-call engineers were to receive compensation for each incident they resolved, it would incentivize them to intentionally build systems that fail so they could increase their pay by increasing their on-call load.” My guy, that is sabotage and fraud. You are hypothesizing a scenario where your subordinates are committing actual crimes. If somebody is doing criminal acts at work, fire their ass! Not to mention that anybody who deliberately self-inflicts on-call load is a goddamn idiot and should be sacked just on that basis alone.
It's a matter of degree.
Sabotage doesn't always mean instant breakage.
In "The Simple Sabotage Field Manual" we learn to slow down the organization by things like "Bring up irrelevant issues as frequently as possible", "Work slowly. Think out ways to increase the number of movements necessary on your job.", and "Do your work poorly and blame it on bad tools, machinery, or equipment."
If you are the person who consistently takes 10x longer than everyone else to fix issues, then someone has a conversation with you. It's not that hard.
Good suggestion and I can see the benefit for honest people, but unfortunately it’s as equally a system for financial abuse for others - sometimes enough to prevent people fixing things during their regular hours just to benefit at other times.
A good counter balance to this might be to offer even more compensation for no incidents, or otherwise well handled incidents that go on to squash types of that incident now and into the future.
Not necessarily, but agree that bad managers or organisations have a tedency to do this.
I guess the ultimate goal is to keep everyone happy right? Everyone has different ideals, you can probably assume the business wants everything to work by spending as little as possible, employees want to be paid as much as possible while enjoying their job. Striking that balance is always a challenge.
Some long haul truckers have a relatively workable pay scale. If it wasn’t for how far they expect you to drive in 24 hours, it might be considered good.
The general shape of it at least makes sense. You get paid when you’re on the road. More if you’re driving than if you’re parked, and more if you drive for more than your 40 hours a week.
That’s true for any hourly paid job. Employers can choose to fire those who don’t work efficiently enough. What they can’t do is not pay people for hours worked —and with tech it’s easy for them to tell how long you are logged in for, to avoid them underpaying you.
It is also in my interest to skip spotting bugs during code review so I can look like a genius when I fix them when they cause issues in production. Of course I don't do that because this is incredibly stupid and I have better ways to spend my time.
10x pay is significant. Personally, I would remediate asap even with $1500/hour on the line. I do have ethical standards.
But would I be as motivated to stop the root cause of the recurring issues that keeps giving me an extra $3k every shift? Well, I probably would, but my coworkers already need to be goaded into fixing root causes, and they're not getting paid extra!
In general, I think conflicts of interest must be handled carefully, and ideally avoided. Paying 10x wages when incidents happen is a clear conflict of interest.
Having overtime pay that is a multiple of regular hourly rate is mandatory is many countries in Europe. Are you saying that European software tends to be more obfuscated? (answer: it is not).
Employees are also subject to the Working Time Directive in EU countries which sets limits to the amount of overtime that is permitted in a week and in a month. Unfortunately in most countries it's full of loop holes.
https://watermark02.silverchair.com/stag328.pdf?token=AQECAH...
mentions 3 three alternative interpretations for GRB 250702B:
1. Ultralong Collapsars: These stellar-engine models can explain long durations but struggle to account for the specific timing of this event. Specifically, they cannot easily produce a 12-hour gradual rise in X-rays followed by a multi-hour peak, as the jet would have to fight through a massive progenitor star while its power is still very low.
2. White Dwarf (WD) Tidal Disruptions: While an Intermediate Mass Black Hole (IMBH) disrupting a White Dwarf could theoretically provide the necessary gravity, the numbers do not add up for this specific burst. The timing between flares is too long for a WD scenario, and the total energy required would demand an unrealistically narrow jet. When physical constraints like detonation are factored in, this model is considered highly unlikely.
3. Micro-TDEs (Main Sequence star by a stellar-mass BH/NS): This is considered a competitive alternative that can explain the burst's sub-second variability and long duration. However, it faces two main issues: current afterglow data suggests the surrounding gas density matches an IMBH environment better than a micro-TDE environment, and the burst’s extreme energy would require very high jet efficiency or a very narrow beam.
reply