edelbitter

>People are really likely to rebuy things. I’m not really sure why

Time consuming research (starting with filtering out advertising budget powered fake reviews) and short-lived products & brands make personal experience & recommendations a lot more useful. If someone around me has an even remotely similar set of requirements and budget for a product, they are much more likely better off trusting my recommendation and (having me) order another one right away. It used to be less clustered around one person or calendar date, when brands stayed around and kept true to their previous performance for longer. Nowadays I even order duplicates for myself, not because I really need 3 of them in the near-term future, but because I am worried that I will want a replacement in a year and another one the year after.. and I won't find exactly the same then.

I found the /etc/apt/sources.list.d/lexicographic-order.list to /etc/apt/sources.list.d/lexicographic-order.sources (Debian RFC822 control data format) migration well-planned: the old format will not stop working before 2029, just newly installed or upgraded systems will not default to it any more. Unless an admin specifically deployed no longer compatible files to a newer release, without even checking how the folder looks there, this slow changeover won't break much. Which is the sort of planning I value Debian for, and hope for whatever cleanup the mirrorlist plus http-redirect bit eventually gets. (There is additionally the somewhat related pdiffs feature, which could suffer from the same category of time-of-check/time-of-use bugs - but that one already is configurable per-repository and less seriously harmful if disabled on a supporting source.)

Since this is the second time the redirect feature was broken in a serious way and there is still no obvious need for it.. time to make it opt-in instead of opt-out?

They test run a little more tests on their backports (and have the manpower to actually look into what is failing) and they have really far out EoL once the kernel release is selected at fixed intervals. So if you managed to get the capabilities that you care about in their tests, there is a low probability that applying updates will cause some catastrophic outage or data loss over the next 10 years. Which can be improved further by fine-tuning phased update rollouts.

Unfortunately, they did in recent history manage to still break iptables, zfs, nilfs and a bunch of machines with weird (arguably broken) firmware anyway, so my personal comparison between Debian (or simply directly the Kroah-Hartman/Levin stable upstream) and the Ubuntu backports is not exactly in favor of Ubuntu.

How about: civility? Because I'd argue that was always the expected, the appropriate thing to do. Always watch for feedback and quickly edit any missed meta-issues with your question. So that during the slim window it can reasonably be shoved into possible answerers faces it will not waste their time.

As long as vision zero is considered more of a gross infringement on personal freedums than a laudable goal, making trains as safe as they are uniquely fit to become is not exactly a great way to allocate funds to maximize impact. Trains are already very safe. Even where they currently lack 4 layers of fail-safe systems operated at a level where that still permits reliable&punctual service. The same money on making them shine could be spent on improving car infrastructure (or even removing some car infrastructure!) for greater expected harm reduction.

There is also plenty of ways to confuse the WAF by simply sending multiple instances of of the relevant header and/or parameter..

If your application is known to routinely "deserialize" (unsafe-eval) strings from a database or cache, an attacker might have placed a tiny backdoor that way, only to be used after the everyone has applied the PHP patches and attention levels & active staff are back to normal.

Scroll down in the actual patches to the weirdness of the multipart parser. That very much looks related to the what can be abused via the upload progress callbacks that had been discussed on (anti)social media.

The previous presence of PHP and its oftentimes ridiculous common practices might mandate a maintenance mode that is a little more involved than just serving HTML.

e.g. if your site usually responds blank for https://site.example/database-passwords-and-other-goodies.ph... but under maintenance mode publishes the configuration verbatim, that would be quickly picked up the usual scanner bots.

A rewrite would tackle the classic C-style W^X problems, at the expense of maintainability and focus on logic bugs and general oversights from inelegant (or lack of) design. And I'd bet PHP (and popular PHP software for reasons rooted in the language) still got plenty of the latter. You know, the "oops, that filename was client provided" kind of code execution that no amount of (un)safe blocks can help with.

I think I see a way to overwrite suitable memory in the parser, so smuggling (as in: confusing another parser) would be purely for bonus points.

Release notes draft filenames (but not contents) are published to the mailing list: https://news-web.php.net/php.webmaster/34116

Cars occupy public spaces where more efficient modes of transport have already been mostly driven out, while delivery robots conquer additional public space.

I find it slightly less weird because I see potential for indirect attacks on the not-quite-so-ECC parts of actual implementations. Wherever a network client can ask many times for each of the different, but somehow not entirely uncorrelated curves, it might be able to expose previously not deemed critical side channels. Following in the general direction of the discoveries that so far resulted in IV and padding determinism/randomness being considered as important as the "actual crypto" itself. In that case the structures that would need to somehow interact would not be ECC and LCG, but merely LCG and key derivation..

This is the reason why this is desirable for humans. But I do not like extending excuses that apply to human (limitations) also to companies that could keep a log.

>they can be hit randomly with 2^30 tries

More precisely: not very random tries.

Remember the currently common margins account for the fact that you actually use some of the water every now and then. That water in the tank will regularly cross the merely transiently safe temperature range, by design.

Once silicon is in control (which is where responding grid requests to delay consumption is more or less necessarily heading) you could even achieve better (worst-case) safety margins at reduced (total) power consumption. Because the machinery no longer needs to be designed around two "dumb" thermo switches and do a little extra in case layers of varying temperature manifest after two or more spaced periods of consumption. With continuous monitoring in software, you can integrate the worst-case bacterial growth based on time elapsed outside the "practically safe" temperature ranges. Then the tank always knows what is needed, and can both operate on tighter margins and reliably know when reducing or delaying power draw is ok.

The current policies are not very enterprise-friendly yet.

Some settings are flat out refused (for "security reasons"). And with each new update there are a few new popups / invitations to try this new feature / re-enabling the v2 of the thing of which the v1 was already opted out in the policy. And it seems like you cannot apply new policy while the browser is running - meaning it cannot be used to roll out hotfixes without interrupting the work of currently unaffected workstations.

And then there is the syncing. If you want to manage & sync history, bookmarks and the password managers content.. you are probably going to find that easier by overriding the builtin features with 3rd-party extensions, as the builtin sync feature is very much tailored to the needs of privately owned devices and one-device-at-a-time usage patterns.

>Professional Support included — private triage and defined response times

This one sounds new to me.

You can forcefully disable hardware acceleration, that removes a few bits - though javascript can still guesstimate your CPU and memory.

For a more proper solution, you could try to convince Mozilla that granting every website uncapped multi-threading and direct GPU access is a bit much. If webgl/webgpu truly is a must, then maybe each website permission should start with a single-threaded software-renderer that behaves indistinguishable on all supported platforms. And only after granting the website that extra permissions let it determine that a more powerful GPU is available.

Preferably after they thought a little more about the more regular fire and/or water ingress hazards.

Now that you can stuff an entire room with only high-G-resistant solid state drives, there should be fewer excuses for losing machines before determining a fire suppression system to be either inoperable or insufficient (but never tested and measured under realistic conditions).

So does eating properly and consistently. A likely expensive but also likely useful study could therefore measure multiple known sleep hygiene approaches in isolation, then in combination, and then look at the degree of correlation in comparison to controls. Some of the observed differences might be cleanly attributed to previously not properly controlled for effects such as irregular meal schedules.

> a particular vision of progress that is informed by history

I imagine there has, for a very long time, not been a need to specifically write down what that field-specific vision is and how exactly history teaches us that there really only is one scientific method. Some future LLM will surely be able to explain this in their place, so mathematicians can stick to their primary fields instead of having to become experts in teaching the theory of teaching.

Are they?

The problem to be solved was not to spew out maximum lines of text containing some greek letters per hour.

It was to write down iterative progress in conceptualizing, modelling and consistently explaining difficult questions - in a way that advances human understanding. If nobody bothers to read through 50 pages of gibberish that may or may not be containing some insight, then the total problem solving remains zero.

The old hardware approach is still king when it comes to effortlessly catching someone "optimizing" something in a way that will break again in just a few generations of whatever Intel is doing. Unfortunately 486 is now gone from linux upstream (better/worse: all TSC-less or CX8-less cpus are dropped).

3.9 tar is on SuSE 4.3 cdrom 3, see https://archive.org/download/suse-linux-4.3

Even when assuming that a decline in hanging out in person is a huge factor, it is particularly bad for the youngest. Because all the suburbia+birthrate trends get much worse at the point where the number of same-age peers within comfortable reach of available transportation drops from 1 to 0. The same basic principle was less awful for the earlier generation that more likely lived through a comparatively mild 3 to 2 drop, and remains less bad for those that grew up just in time to make up for the distance with reasonable affordable petrol.

The point about gambling is hard to argue against. Abolishing (or simply stopping enforcement of) various gambling bans around the world, especially those specifically scoped for the youth, is a fairly recent development. Upholding those bans took constant investment - the incentives to tear down the protections were always there.