> Note nevertheless that the journalist has also failed to point out a particular interaction that would support their thesis. For searches that trigger this "promotion", the window immediately scrolls the page so that the promotion is aligned to the top of the viewport, and the search bar in the promotion is focused. (The "Promoted by Microsoft" is visible without scrolling at any size.)
That's what I said. This is still in contradiction with the screenshot, which I described as:
> The journalist has manipulated the browser window's size and scrolled down a bit so that only the "promoted result" is visible and without any indication.
where the "Promoted by Microsoft" is NOT visible. I find that dishonest.
Ads work around lack of autoplay by loading massive image filmstrips containing video frames (often split across hundreds of image files), and animating that in JS or CSS. This has all the annoyance of autoplay, with even worse bandwidth and memory usage.
Using individual components instead of the whole big framework isn't necessarily a failure. The components are designed to be usable independently.
TinyGlade project started a few years ago, when Bevy's rendering was even more basic. The art style is central to TinyGlade's appeal, so it's not surprising they've built a custom renderer.
DRM is really about control. It's a technical trick that thanks to DMCA anti-reverse engineering clauses becomes a legal trick to dictate exactly who and how can play the content, much tighter than what copyright and consumer laws allow by default.
For example, without DRM you couldn't effectively sell separate licenses for computer screens and TVs, because users could just connect their computer to a TV.
DRM allows negotiating everything about distribution, up to who pays who for having a button on the TV remote.
Those who control the DRM have a veto power over everything, and have it viciously enforced internationally thanks to it being tied to copyright.
What are you talking about? You can connect your computer to a TV just fine. No, lost sales are not 'just a convenient excuse', the sales they lose to piracy are far more numerous than the ones they'd gain with this fictional system that relies on people being willing to throw away money for no reason. 'It's about control' is a favorite element of conspiracy theories but corresponds to no real-world corporate need.
Rust ecosystem solves that by providing packages that are thin wrappers around underlying APIs. It's very similar to providing an .h file with extra type information, except it's an .rs file.
Correctness of the Rust wrapper can't be checked by the compiler, just like correctness of C headers is unchecked, and it just has to match the actual underlying ABI.
The task of making a safe API wrapper can be relatively simple, because you don't have to take into consideration safety an application as a whole, you only need to translate requirements of individual APIs to Rust's safety requirements, function by function. In this case you would need to be aware that the function call may unwind, so whether someone making a dedicated safe API for it would think of it or not, is only a speculation.
I seem to remember a linux kernel dev quiting and not being able to specify exactly what you say this wrapper should abide by as being a contributing factor.
If those specifications were written down clearly enough then this dev wouldn't have needed to spend 5 days debugging this since he spent a significant amount of time reading the documentation to find any errors they are making that is mentioned in the documentation.
And don't say that they can actually just read the rust code and check that since well, I can't read low level rust code and how any of the annotations ca interact with each other.
A single line of rust code could easily need several paragraphs of written documentation so that someone not familier with what rust is specifying will actually understand what that entails.
This is part of why Rust is difficult, you have to nail down the specification and a small change to the specification causes broad changes to the codebase. The same might need to happen in C, but many times it doesn't.
That Linux drama was due to "nontechnical nonsense" of maintainers refusing to document their APIs requirements.
In C you can have a function that returns a pointer, and get no information how long that pointer is valid for, what is responsible for freeing it, whether it's safe to use from another thread.
That's not only an obstacle for making a safe Rust API for it, that's also a problem for C programmers who don't want to just wing it and hope it won't crash.
The benefit of safe wrappers is that as a downstream user you don't need to manually check their requirements. They're encoded in the type system that the compiler checks for you. If it compiles, it's safe by Rust's definition. The safety rules are universal for all of Rust, which also makes it easier to understand the requirements, because they're not custom for each library or syscall. The wrappers boil it down to Rust's references, lifetimes, guards, markers, etc. that work the same everywhere.
Fisheries are a significant part of Iceland's economy, though.
Well-off European states with lots of sea (Norway, Iceland, Greenland, the UK) are disproportionately likely to reject EU membership due to the Common Fisheries Policy.
It's too bad that the EU failed to recognise, way back in the EEC days, that having all these countries in the EU was far more important than some fish. (And just wait to see what a huge problem the Common Agricultural Policy is going to be for Ukrainian membership.)
Ukrainian membership will hopefully never happen (unless Ukraine actually shapes up into a modern country first). Without the war the process would never have gone as far as it has already.
What makes you think that the reforms that have been going on since the war began aren't evolving Ukraine into a "modern" country similar to Romania, or Bulgaria, or Slovakia, or any of the post-Soviet members?
Not OP, but I think there's a valid argument about how "modern" those countries are. It's generally accepted that Romania and Bulgaria were let into the EU somewhat early, mainly for geopolitical reasons (foreclosing Russian influence there, cutting off Russia from the West Balkans). They are countries that continually lie on the tail end of every EU statistic, and have relatively unstable domestic politics and rule of law.
Personally, I'd like to see Ukraine in the EU asap, but I'd also like the EU reformed into a democratic federation, such that the equivalent of the FBI has meaningful authority to investigate and prosecute corruption and rule of law irregularities in member states like Ukraine and Bulgaria.
Entirely agree on what you would like to see. My point is that Ukraine is no worse than any of those nations, so admitting them to the EU is hardly going to affect the EU in any bad way.
Integration would be difficult on the agricultural front, but is something that the EU has been dealing with since inception.
One of the "benefits" of the war and the Ukrainian diaspora throughout Europe is that they will be able to integrate much faster than the previous Balkan and Balkan-adjaent countries as integration into Schengen would be able to be rapid.
Ukraine's engineering, mining, and agricultural industries would bring major advantages to the EU as a Union, diversifying engineering from dependence on Germany, and bringing broadscale agricultural efficiencies to the EU as well.
> integration into Schengen would be able to be rapid.
If there is one thing that Western EU countries have learned over the last 30 years, is that borders should be opened very slowly. With the current "black wave" sweeping the continent, there is no chance in hell that Ukraine will be admitted to Schengen in less than 10-15 years - if at all.
I'm not trying to rain on your parade, I'm just being realistic. Ukraine has all the problems of countries that were admitted to the EU too quickly, plus all the problems coming from scale and an agrarian economy. Just waving it in the EU would be a repetition of all the major missteps of the last 30 years.
> there is no chance in hell that Ukraine will be admitted to Schengen in less than 10-15 years - if at all.
The main concerns about new states joining Schengen are usually that (a) there may be too many immigrants from the new member to the old members, and (b) that the external Schengen boundaries will be insufficiently protected by the new member state.
Neither problem applies to Ukraine - Ukrainians have had essentially free migration access to the Schengen since 2022, and Ukraine's borders with third-party states would be - by far - the best defended. Ukraine could join Schengen very easily (unlike the EU itself, which may indeed take years). I wouldn't be surprised if Ukraine becomes part of Schengen well before it joins the EU, á la Iceland.
Hopefully this war will be over very soon, and soon after there will be a boom of children born in Ukraine, as happens after wars.
They'll have all sorts of issues, but has there ever been a nation that has been so unanimous about wanting to join?
I think NATO membership is more likely to occur before EU membership, Ukraine won't accept anything less for their future protection, having fought the Russians to a standstill.
EU integration is more about the economics first. For example, Ukraine just cut off traffic of Russian oil/gas across its territory. That was a source of income for Ukraine that will have to be compensated after the war. Perhaps via damages paid by seized Russian assets.
What I hope that both of these perhaps decade long paths start in 2025.
It would make a good celebration in 2035 if both of those things have happened.
NL fishing fleet has been modernized twice over. First cleaner engines, then electric pulse fishing (not nearly as bad as dragnet fishing).
French fishers don’t want to make the investments into their fleet, so they harassed French politicians until those spiked the pulse fishing research permits. This had the by-effect of (nearly) bankrupting the Dutch fishing fleet.
So no, fishing industry fights are not just an UK thing.
rustfmt uses 100-char lines by default (and can be configured to fill more), but that's not the problem with it.
The problem is that as soon as a whole statement doesn't fully fit on a single line, rustfmt switches from "horizontal" to "vertical" strategy. It then stops caring how much vertical space it takes, inserts line breaks as often as the style allows, and won't try to use the available line width.
You end up with long runs of finely chopped lines that contain only a single variable or a single call (often with each argument on a separate line too), which looks like having a 20-char line length limit.
It's either fully oneliner `foo().bar().baz()` or fully vertical
foo()
.bar()
.baz();
and you can't have anything in between. It will fight you if you put two calls on the same line.
- There are only two strategies and the algorithm to choose between them is trivial for a human to compute. This makes for way better readability, you can reliably predict where the next call/argument is going to be positioned.
- Refactoring becomes easier - moving an argument is now a simple `Line up` editor action.
- Source control diffs become more stable across changes.
...but it's hard to see the benefits on trivially simple examples like the one you presented. Here's a reformatting I did [1] to illustrate this:
Original:
ReturnType<SomeOther<S, TypeConstructor<Nested<S, T, U>, T>>, U, HmmLetsAdd<V, W>>
You rename a method, now it's a few chars shorter/longer, and some 1-liner call sites can become completely rewritten to the vertical style or vice versa.
You delete a single line, now the expression can fit under a threshold, and the whole block is spaghettified (especially terrible when deleting a struct field).
You wrap code in an if{}, which could have been a clean whitespace-only change for the entire body, but the indentation affects rustfmt's char counts, and it will now force different formatting decisions all over the place.
If you're changing an infallible method to a fallible one, you could have added error handling/fallback on separate lines, keeping changes to the happy path minimal – but not with rustfmt.
For minimal diffs you'd want something with a slack like gofmt, but rustfmt completely overlooked what makes gofmt so great and widely acceptable, and is a misanthropic ruthless canonicalizer instead, which ruins lots of use-cases, including minimal diffs.
Rustfmt's heuristics aren't simple. They're based on char counting of AST nodes, with multiple different limits for different node types, and crossing any threshold can trigger an avalanche of reformatting. There are more complex rules for closures and comments.
These heuristics are a source of formatting inconsistencies, e.g. each match arm is evaluated independently. Even when all match arms contain the same code, they can be formatted wildly differently due to patterns/name lengths pushing different thresholds. Indentation and AST context can make the same expression look differently each time.
Such problems largely don't exist in gofmt, so it's not a problem of code formatters, it's a problem of rustfmt specifically.
This is an inaccurate generalization of both C and Rust ecosystems, and an inflammatory framing.
openssl has made several rounds of incompatible changes. ffmpeg and related av* libs make major releases frequently. libx264 is famous for having "just pin a commit" approach to releases.
It's common for distros to carry multiple versions of major libraries. Sometimes it's a frequent churn (like llvm), sometimes it's a multi-year migration (gtk, ncurses, python, libpng).
C libraries aren't magically virtuous in their versioning. The language doesn't even help with stability, it's all manual painstaking work. You often don't see these pains, because distro the maintainers do heroic work of testing the upgrades, reporting issues upstream, holding back breaking changes, and patching everything to work together.
----
Cargo packages almost never pin specific dependency versions (i.e. they don't depend on exact minor/patch version). Pinning is discouraged, because it works very poorly in Cargo, and causes hard dependency resolution conflicts. The only place where pinning is used regularly is pairs of packages from the same project that are expected to be used together (when it's essentially one version of one package, but had to be split into two files for technical reasons, like derive macros and their helper functions).
By default, and this is universally used default, Cargo allows semver-major-compatible dependency upgrades (which is comparable to sover). `dep = "1.2.3"` is not exact, but means >=1.2.3 && <2.0.0. The ecosystem is quite serious about semver compatibility, and there is a tooling to test and enforce it. Note that in Cargo the first non-zero number in the version is the semver-major.
> ffmpeg and related av* libs make major releases frequently.
True, not every lib keeps long-term stable API.
> It's common for distros to carry multiple versions of major libraries. Sometimes it's a frequent churn (like llvm), sometimes it's a multi-year migration (gtk, ncurses, python, libpng).
This is consistent with what i wrote as these are changes in major versions.
> C libraries aren't magically virtuous in their versioning.
My statement was not categorical statement about C libraries, but it was about incentives shaping the ecosystem. Using libraries has costs and benefits. Frequent churn means higher costs, so it is acceptable when bringing higher benefits. In the C ecosystem, the cost for major version churn (or general library API incompatibility) is high, so people avoid it when possible. If sophisticated tooling like Cargo makes building against specific versions easy, it lowers the cost of churn, so everyone is less concerned with it.
It is true that in C ecosystem, keeping stability is not effortless, for software developers it means running CI with tens of distros / distro versions, to test their software against diversity of library versions. Not 'just use my Cargo.lock' (i am not sure how widespread this approach is in Rust ecosystem, but at least some people argues for it in this discussion).
