2,827 karma · joined October 6, 2014
Now that you raised it however, even if the system call used to be fast, Firefox is making an extremely high number of calls to that sytem call, and there's always going to be some overhead to that. There are almost certainly ways that Firefox could reduce the number of calls it needs to make.
Instead we have this abomination which is worse for everyone involved. It doesn't improve performance because it forces extension authors to hack around the broken API, and in doing so waste CPU and memory.
Firefox FTW
That said, there are some general themes:
- The lack of implicit magic in the language. Destructors (specifically the fact that they are called automatically) is implicit. That's it.
- The context-free nature of the language. This exists at several levels:
1. At a function level. There is no cross-function inference and all the information about a function is in its signature, so you don't need to look anywhere else to understand what it does.
2. At a module level. Everything you use from elsewhere is explicitly imported in the module. There's nothing that can change what a piece of code does across a crate (eg. the way you can just redefine `true` to something else in C/C++.).
3. At a file level. The module hierarchy is explicit, it is not inferred based on the layout of files on disk.
Together, these things means you can look at a piece of Rust code and understand it in isolation, without even needing to be familiar with the codebase as a whole. You can move a piece of code from one location to another and (aside from fixing imports) can expect it to continue to function exactly as it did before.
- The fact that it can be used as a safe language. This is not unique to Rust, but Rust is unique in being suited to the lowest-level tasks whilst still being safe. Safety limits the damage a bad refactoring can do (at worst, you break the code being refactored, but at least you won't give the whole program UB or cause a segfault).
- The fact that macros operate on the AST rather than text. This eliminates a class of bugs with C-like macros, where implementation details of the macro have a tendency to leak through the macro definition. Refactorings can often trigger these kinds of bugs because you cannot easily think at that level while doing a large refactor.
- The tooling. Whether it's quickly knowing the type of a variable, swapping out a dependency, or applying broad fixes to a codebase, the tooling works extremely well together.
- Consistency of the language. Everything is an expression. "void" is just a normal type, etc. This level of consistency means that large refactorings require fewer actual changes than they might do in other languages. For example, when I used a bit of C# again after using Rust, it was very noticeable the amount of "pointless" transformations I had to do when refactoring because making an expression conditional may require introducing a new variable because `if` statements cannot be used in an expression. (Yeah there's the ternary operator, but it can't be used in every case, and that's just another example of inconsistency).
It has some cool features too, like not injecting anything into pages until you activate it (so no performance cost or risk of breaking sites) being less reliant on perfect detection of fields when it is activated, etc.
This is latest stable Firefox on a high spec Windows 10 laptop.
Not a great look given what React is supposed to do!
If they applied a perfect digital gaussian-blur, then that is reversible (except at the edges of the image, which are black in this case anyway). You still lose some detail due to rounding errors, but not nearly as much as you might expect.
A gaussian blur (and several other kinds of blur) are a convolution of the image with a specific blur function. A convolution is equivalent to simply multiplying pointwise the two functions in frequency space. As long as you know the blur function exactly, you can divide the final image by the gaussian function in frequency space and get the original image back (modulo rounding errors).
It is not totally inconceivable that the AI model could have learned to do this deconvolution with the Gaussian blur function, in order to recover more detail from the image.
ie. the issue is not with how we define the second. The issue is expecting that if two people in different frames of reference wait for one second, that they will continue to be "synchronised".
In fact it's worse than that, it's impossible to even define the concept of "synchronisation" for entities in different locations. You can only know that two things are synchronised if they are in the same location.
If the two entities are in the same frame of reference (ie. not moving or accelerating relative to each other) then you could argue that you just send a beam of light there and back, and assume the light takes the same time in each direction in order to synchronise... But we don't even know that light travels at the same speed in all directions! We've never been able to measure the "one-directional" speed of light, we can only measure the round-trip, so for all we know light could have a preferred direction in the universe and travel faster in that direction, as long as it is the same amount slower in the other direction. We would never be able to tell.
> For each half hour, known as a Settlement Period, companies can trade up to 1 hour beforehand that time period is closed.
If you're referring to the consumer energy price cap, then that's not even relevant to this discussion, since the price cap applies to households, not commercial charging stations...
First, companies can catch most fraudulent documents simply by looking at the document (eg. are the fonts all correct, does the checksum on the MRZ add up, does the data in the MRZ match the data on the face of the document, does the data on the document match previously collected data about the individual, etc.) Some will go further by combining this with a "liveness" check (eg. they might ask you to take a picture of yourself in a certain pose, or to record a short video looking side to side)
Second, companies can use a soft credit check (if authorised by the user, which would need to be in the fine print when you sign up or when you are asked for such a document). Such a credit check won't affect your credit score, but can be used by companies to see if an individual with your details exists. Companies which offer such credit data in the UK/US/other western countries typically boast of 90-95% match rates across a population, but obviously younger people are less likely to be found since they are less likely to have a credit history. This is typically aggregated with data from non credit sources (electoral roll information, county court judgements, etc.) to reach those high match rates. They might also geo-locate the IP address from which you accessed their site and compare it against any address information they have on you (which could come from you providing it on sign up, it could be extracted from the document if it's a driving license or something, or it could come from any credit records they found relating to you)
For Facebook specifically, they might look at other online activity - other social media accounts they can link to you, etc. And throw all of that into the mix.
If at the end of all that they don't have a clear answer, they might fall back to a manual process, or allow the account to be created but have content posted by the account flagged for manual review.
One advantage of these kinds of "localised" garbage collection approaches compared to typical GC is that the cost scales with the size of the specific collection, as opposed to with the total allocation rate / memory usage of the entire program.
Even if it's not smart enough to do that today, it could implement this optimization in the future. This could work even without inlining, since the Rust calling convention is unstable, and an optimization based on type size could be incorporated into it.
To solve this, in most countries, companies are taxed VAT instead, so intead of taxing the total value of product at every step, you are only taxing the value the company adds in the process.
Effectively the government is taxing the total value of the product at a fixed rate once but that tax is being split among the companies which helped supply that product proportionally to the value added by each company.
You know what would be useful for cavemen to ponder? The safety of fire. Or you know, just staying alive because there are more dangerous things out there.
The current state of so-called "AI" is our fire. It's impressive and useful (and there are real dangers associated with it) but it has no bearing on intelligence, let alone superintelligence. It's more likely that a freak super-intelligent human will be born than that we accidentally produce a super-intelligent computer. We produce a lot of intelligent humans, and we've never produced a single intelligent computer.
As it stands, we don't have the understanding or the tools to do anything useful wrt safety from a super-intelligent AI. We do have the understanding and tools to do something useful about asteroids and climate change.
It's far more doable than you are suggesting: fuzzing automatically covers most branches anyway, so you just need to manually deal with the exceptions (which are easy to locate from the code coverage).
I used fuzzing to test an implementation of Raft, and with only a little help, the fuzzer was able to execute every major code path, including dynamic cluster membership changes, network failure and delays. The Raft safety invariants are checked after each step. Does this guarantee that there are no bugs? Of course not. It did however find some very difficult to reproduce issues that would never have been caught during manual testing. And this is with a project not even particularly well suited to fuzzing! A parser is the dream scenario for a fuzzer, you just have to actually run it...
I mean... It is pretty actionable TBH. There are sanitizers you can use to detect UB. You could use a memory safe language. You could use a fuzzer. You could improve your test coverage. You could use static analysis tools. All of these can help reduce the chance of UB in your program.
Also the author's condescension about automatic memory management is... telling. Remembering to call "free" is only one small part of why tools like RAII are good, and arena allocators do not help with the other parts.
The overall goal is to be able to write correct, reliable, performant software. Arena allocators help prevent missed or double frees, but they don't help with the other memory safety issues. For example, sometimes objects in different arenas need to reference each other and C does not help prevent you from accessing those references after one of the arenas has been freed.
On top of that there are general issues with arena allocators:
1. They can be inefficient for resizable collections where you don't know the total length in advance. The multiple re-allocations results in a lot of wasted space in the arena.
2. In C, it's implicit which objects should belong to which arena.
3. It's not composable. A library doesn't necessarily know which objects should use which arena, or may not even support arena allocation at all.
4. There are other resources than just memory. There's a reason it's called RAII and not MAII - because it allows you to clean up all kinds of resources (eg. file handles) when an arena allocator doesn't typically support any kind of destructor.
5. It requires more thought to structure your program in this way. For some programs that may be effort well spent, but a lot of programs are not bound by allocation performance, and for those programs not thinking about allocation at all leaves more time for thinking about correctness in other aspects.
6. Languages which do automatic memory management can still support arenas, and may offer additional benefits when they do (eg. Rust's explicit lifetimes can tie an object to the arena it came from).
7. The stack and heap are global resources that most code can simply assume exist, and use with no extra ceremony. When you have arenas in play, these need to be passed as additional arguments. Adding a new allocation to a function can require sweeping changes to add a new arena parameter to every function above it in the call stack.
It sounds to me like the Python buffer protocol is under-specified, which can lead to data races in native code.
Here's an example of how this could occur without Rust being involved:
- Two python threads with a shared buffer object
- One thread instructs a C extension to write into the buffer
- The other thread instructs a C extension to read from the buffer
- The buffer is implemented to return the same pointer for reads and writes (not forbidden by the spec https://docs.python.org/3/c-api/buffer.html#buffer-request-t...)
- The C extension releases the GIL while accessing the buffer (explicitly allowed by the spec)
In this case, the C extension is reading and writing to the same buffer at the same time without the use of atomics, which is the definition of a data race, and therefore triggers UB.
IMO, the best fix would be for the buffer implementation to expose a "concurrency mode", and require that users of the buffer API use the concurrency mode specified by the buffer when accessing it. In one mode, no synchronization is necessary because the buffer only ever hands out one writable pointer or multiple readable pointers but never both. In another mode, you might be required to have the GIL, in another mode there might be a buffer-specific RWLock you have to hold while accessing it.
The MWI is a simpler theory than other interpretations because it does not require "collapse" to be a physical process. The "realness" of the other worlds is untestable, but also not part of the theory.
"unreal" MWI should be the null hypothesis given what we know to be true about quantum mechanics. If we find evidence that collapse is a physical process then we can reject it, but otherwise it makes the fewest leaps. At the moment the Copenhagen intepretation is taught instead, which is a problem. To quote wikipedia:
> There is no uniquely definitive statement of the Copenhagen interpretation
And
> the device used to observe a system must be described in classical language, while the system under observation is treated in quantum terms
In other words, it does allow you to predict the result of an experiment, but we know it can't be right because it's impossible to formalize without building this "classical observer" into the model. Attempting to build on this inevitably leads to metaphysical nonsense about consciousness.
In "unreal" MWI there is a universal wave function, and something is "real" to us if it is entangled with us. The "many worlds" terminology makes it easier to visualize but doesn't mean those other worlds are real because whether something is real is subjective in this interpretation. Subjective reality may be a problem for some people, but if you look at the evolution of physical theories, we consistently find that everything is more subjective than we thought it was (see also: relativity).
That certainly wasn't my impression from the mailing list. There are certainly some challenges with incorporating colour management into Wayland's model, but they also seem quite solvable (and the mailing list discussion seemed to end up with a solution).
Meanwhile the discussion on pixls seems to be a bunch of people complaining either that it's not solved yet, or if it is solved it won't work the same way it does on X.
The only remaining point of contention on the mailing list came down to colour calibration: one party wanted an API that allowed setting a temporary display-wide colour profile for the purpose of calibration, as this is how it has worked before. The response from a Wayland developer was that there should be a dedicated calibration extension that would allow setting a linear colour space for a specific region (eg. one matching the display). One of the reasons given for this is so that if the calibration application crashes, it doesn't leave the display in a bad state.
My understanding of the full solution is that applications would be able to specify a colour space for each buffer, and the compositor would do the appropriate transformation if that colour space does not match the actual display. Furthermore, there would be events given to the application when a window leaves/enters a display so that it can (if it wishes) choose to handle the colour space transformation itself by setting the buffer to use the same colour space as the display it is currently on. This means you get approximately correct colours when moving a window between displays, even before the application has had time to repaint itself, whilst also allowing the compositor flexibility like reusing the same output on multiple displays, displaying a preview of a window, etc.