devit

A silver-coated umbrella is very effective at protecting the face as well as some of the upper body (or the whole body, if the sun is directly overhead or the umbrella is huge), except for UV reflected from elsewhere which I think is usually not significant.

Another instance of a trivial and obvious feature that can only really be designed one way that is not implemented 4 years after initial proposal.

For some reason the Rust project seems to be plagued by glacial development speed, with features taking years and years to be stabilized after design and often even after initial implementation.

Not sure why, progress used to be way faster years ago.

For example, this "four year plan" should be implemented in 6 months at most, not 4 years.

And the "long-term features" that "should be considered carefully, could not be addressed in the next few years" (lol, seriously?!?) should have serious work start right now and be released as part as the next edition in 2024 (since they need an edition break to be ergonomic). These are basic misdesigns of the type system that should have been fixed 10 years ago.

Whoever is managing and paying for the Rust developers needs to fix this.

The code just ignores variable declarations. All variables are 16-bit words.

It just hashes the variable name and uses twice the hash value as the address of the variable in memory

For functions instead it uses twice the hash to store and lookup the function address at compile time, dedicating the whole compiler data segment except it seems for ds:0 to that table.

Note that in segmented x86-16, the code (plus constants) and stack are in dedicated segments, and string functions used to write the generated code write to yet another segment selected by es.

This seems to be the best strategy for compiler code size, although obviously it's vulnerable to hash collisions and only supports global non-array variables.

Why do people use pills rather than copper IUDs? At least based on information on the web, it seems copper IUDs are strictly better: cheap, easy to insert and remove, nothing to do after initial insertion, no side effects other than "increased menstrual flow".

1. You learn about those and not the ones who successfully hide and keep a low profile

2. Proper security takes time and effort, so there is less time to devote to actual business, which means they are less likely to be successful at a scale that makes them widely known

"An element p of a commutative ring R is said to be prime if it is not the zero element or a unit and whenever p divides ab for some a and b in R, then p divides a or p divides b"

1 is a unit.

The article claims that deferred rendering doesn't support MSAA, but this is only true for a naive implementation.

You can, for example, generate a stencil mask of complex pixels in the prepass and use hierarchical early stencil reject to run a per-sample pass for complex pixels and a per-pixel pass for non-complex pixels (with imperfect SIMD lane utilization).

You can also use a pass to process the complex pixels mask and collect a buffer of (x, y, sample) coordinates to allow a later single hybrid per-pixel/per-sample compute shader pass with perfect SIMD lane utilization.

They computed results for a bunch of 36-empty-squares positions on their clusters and uploaded them to https://figshare.com/articles/dataset/Analyses_of_the_Game_o...

The script at https://github.com/eukaryo/reversi-scripts/blob/main/reversi... plays perfectly (assuming the whole thing is correct) a bunch of data computed by other scripts in the repository using the 36-empty-squares solutions, for which a regular machine is presumably suitable.

It seems that what it does is essentially look up a <=300GB table with all positions with 37-64 empty squares reachable from the weak solution, and runs edax with "-solve" for positions with <=36 empty squares.

Can't you do most of what scrub would do with something like:

   find . -xdev -print0|xargs -0 cat > /dev/null

(ideally replacing cat with something that continues after errors)

Is there any feasible way to run a non-Android OS on a phone and still have power efficiency and support for Android apps with multitouch, GPU acceleration, etc.? (i.e. some ready made solution that runs Android in KVM efficiently, or provides the Android kernel features and userspace RPC servers)

Without that, one must run Android to get access to mobile apps, which is essential.

If you need GPIO you can just get an USB GPIO interface like the one at https://www.adafruit.com/product/2264

This is what GPT-4 produced when asked to remove the bullshit:

SiFive Update - October 26, 2023

After years of growth, SiFive has reassessed its strategies and operations to focus on the most promising opportunities, leading to a restructuring. We believe this change is essential for our continued growth and industry leadership.

We are financially stable and continue to secure revenues and royalties from leading semiconductor companies. We are focused on maintaining our technological edge with investments in advanced R&D.

We recently launched the SiFive Performance P870 and SiFive Intelligence X390 products. Our commitment to our four product families: Essential, Intelligence, Performance, and Automotive remains strong, targeting sectors such as AI, ADAS, Electric Vehicles, Wearables, and Mobile.

With the increasing industry emphasis on AI and the need for adaptability in product design, SiFive aims to offer products that cater to these evolving needs.

SiFive has restructured to increase our agility, strengthen partnerships, and maintain our leadership in the RISC-V domain.

Regards,

Patrick

Use a Pixel phone running version of GrapheneOS built and signed by you with your own keys, or use stock GrapheneOS and don't lock the bootloader, and add root access if desired.

That's the only hardware/software system that guarantees both total freedom, support for mainstream apps, good security and a quality device.

The simplest definition of natural numbers is as the free algebraic structure generated by a nullary and unary operation (conventionally named "zero" and "succ"), which makes it natural to associate zero as the value of the nullary operation, so that one can be it's successor and addition by one works as expected.

Not having zero and associating one as the result of the nullary operation works as well, but then the natural definition of addition will result in x + y - 1 rather than x + y and it seems likely extension to rational numbers would not give an intuitive result.

You could wear an FFP2 or FFP3 mask with a valve.

The whole point of this attack is to be able to make a lot of requests for each IP address.

If you are making one or few requests per IP you don't need this attack, and also aren't likely to have any effect on a Google-sized entity.

Isn't this trivially mitigated by throttling?

And the throttling seems even simple: give each IP address an initial allowance of A requests, then increase the allowance every T time up to a maximum of B. Perhaps A=B=10, T=150ms.

If you have a reversible connector, then you might be entangled in a dilemma of which way is the "better" or "optimal" or "canonical" way, while with a non-reversible one there is only one way and thus no dilemma.

And in fact USB-C is not really physically reversible, because the hardware detects which way it's plugged in and permutes the signals, as opposed to mirroring all the wires, so there is indeed a "right" way of inserting an USB-C plug, except it's impossible to tell which it is without a dedicated hardware tester.

The sort function has no reason to ask for all three comparisons.

Rather, it can ask for two comparisons and act according to the results (e.g. it learns that 1 < 2 and 2 < 3 and returns [1, 2, 3]).

This makes the output unspecified in general, but it will be consistent with the information received and the calls made even if the comparator doesn't form an ordering, which is what one would expect.

"Unspecified order" seems a poor guarantee.

I think a sort implementation should return elements in an order consistent with a subset of the comparison calls it makes, and that subset should be such that it fully determines the order.

An even better guarantee is that the subset should be the whole set of comparison calls.

In my experience most of the flagship phones are slippery enough that it's not a rare event to drop them if you don't use a case made out of a higher friction material.

Of course that's an incredibly dumb design, but unfortunately they are made like that.

"I think this is a consequence of variables being sent to a channel effectively having their address taken, disabling register allocation for them."

Looks like the Go code generator and optimizer is absolutely terrible, since any reasonable optimizer has standard optimizations that prevent this.

Apparently they wrote their own rather than using something established like LLVM, and this is the result.

Getting non-native games to run on emulators can sometimes give a similar experience.

You can also do things like having a Linux machine with a powerful GPU but no GUI installed.

They could drop Gecko and switch to Blink/Chromium.

Then Firefox would be guaranteed to be strictly better than Chrome, since the baseline is the same and they can put in all the features that Google doesn't want because they would reduce their ad income, such as great ad-blocking support.

This might result in losing Google's search engine deal, but they can probably make a similar deal with an LLM-based search engine and even if the money might be less they don't need that much if they are only maintaining a fork and not the whole engine.

It seems that the problem is that the Onewheel is a fundamentally flawed design that should perhaps not even be legal to sell.

Basically the issue is that the only control available is turning the wheel, but an unstable scooter actually needs two controls: one to balance the board and one to control the speed.

Having a single control means that they are tied and thus that, discounting air resistance, if the user continuously leans forward, then the board has to continuously accelerate up to arbitrary speeds since turning the wheel to balance also results in acceleration.

Furthermore, it seems that they don't even have a motor powerful enough to always be able to balance the user along with air resistance, so if the rider continuously leans forward eventually the motor is no longer powerful enough, the board loses balance and the rider probably falls down and dies.

Not sure how they could even think of selling a design like that or how they are surviving the lawsuits.

The simplest fix seems to be using four wheels instead of one, which also removes the need of active balancing and is a normal proper design. If "leaning to accelerate" is desired instead of a more normal handle with a throttle control, then it should be achievable by adding suspension springs and detecting their extension.

Not sure if it's possible to have a proper design with one wheel; a thing that comes to mind is having a sort of "landing gear" that can come down and make the board stable on demand. An alternative could perhaps be an internal reaction flywheel, but not sure if that works and is feasible.

Buy something comfortable instead, such as an Exped Megamat 15 LXW plus a memory foam topper and maybe a foldable cot.

Seems very uncomfortable and only useful if someone really can't afford the $100-300 for a normal camping air or self-inflating pad, which seems miles better than this.

And if you are OK with uncomfortable then a simple closed-cell foam mat, while possibly a bit more expensive, seems far more reliable, durable and cleanable than this.

I think it would be very useful for scouting in woodland/backcountry use including search&rescue.

At 50 km/h, it moves 10-20 times faster than a hiker, and at <1000$ it's more than 100x cheaper than a plane or helicopter.

But requiring line of sight is a strong limitation because it means that you need to fly over the tree canopy and might not see under it, and you need to fly really high if target is on the other side of a mountain or hill and again you might not see well.

And of course cell phone coverage is not guaranteed so you can't use the easiest solution of putting a cell modem on it.

Is there any system that works for at least 10-20km without line of sight, supporting a video feed usable for guidance, without cell phone network coverage?

Maybe something where there are two drones, and one flies high with line of sight to both the user and the low-flying drone so that it can act as a relay like a satellite would?

Or something that uses radio frequencies that bounce over the atmosphere, and if bandwidth is not enough uses an automated pilot plus the ability to send photos every few seconds so the user can tell it in which general direction it should fly?

Or something that uses Starlink/Iridium/etc. to relay data?