Blink supports Windows, Android and Linux better than WebKit or Gecko does, to name at least one one reason. If it weren't for uBlock I'd probably be using a Chrome fork right now.
Google has already shown that they will slowly and methodically use every lever at their disposal to nerf ad blocking, regardless of what the user base thinks.
It's the exact same playbook Microsoft is using to block users from logging onto their own computer without using an online Microsoft account.
Given that Google has already started working to limit sideloading on Android, those days seem limited.
Blink is an open source project. If Google updates Chrome and Android to refuse sideloading at all, you can still fork both projects.
Your entire argument relies on a hypothetical you can't prove and doesn't scare anyone. To Android users you sound more like Chicken Little than the Boy who Cried Wolf.
Wipr and UserScripts on Safari prove to me that that's not a real issue...I understand compatibility problems are still issues, but ads/etc. are a fully solved one for Safari users.
For me it’s a lot of layout and rendering bugs that I run into with somewhat normal CSS transforms.
Anytime I build a site that has any kind of animation, there’s at least one weird rendering bug on iOS.
Also that stupid playsInline prop that if you forget it makes any video in the viewport hijack the browser and go fullscreen.
WebKit is not lacking in things your average dev needs and it’s not that big of a deal to work around, much like it’s not that big a deal to work around things in Gecko - or presumably Ladybird whenever it becomes usable enough.
Like, they may have trained on power lines, catenaries above rail tracks, network cables, etc. but all of them are horizontal. And the software couldn't recognize vertical cables or cables at an angle.
You may have a tall mas or an antenna and massive cables stretching at angles around it for support. The distance between the base of the mast and the base of supporting cables can be quite large, so even a simple logic like "stay 100m away from tall structures" can be insufficient.
It would be interesting to see what comes out of this investigation. Hopefully the injured person will be alright.
But then how do you deliver to the upper floors of vertical buildings? That must be half the near-term market for these kinds of drones: people in dense, urban areas well-served by local droneports, who are looking for convenience above all else.
If you can't safely manage urban canyons—you can't manage. It'd be like selling self-driving cars that are only approved for private racetracks.
Here's a curious article I read the other day, that underscores the market factor:
https://news.ycombinator.com/item?id=45445406 ("What It Takes to Get Lunch Delivered to the 70th Floor in a Shenzhen Skyscraper (nytimes.com)" / "An informal network of last-mile runners close the gap between harried delivery drivers and hungry office workers in a Shenzhen skyscraper")
> But then how do you deliver to the upper floors of vertical buildings?
Elevators, dumbwaiters, baskets and pulleys, or just go downstairs and get it yourself.
Also, how tall are we talking? Where have you been where the upper floor windows actually open?
edit: the more that I think about this, the more it bothers me. Getting close enough to a building to deliver a package through a window with a drone sounds incredibly improbable and dangerous. A small gust of wind and the drone crashes into the building. You'd need some kind of pad at a distance from the building, or use the roof. Looks like there's a design for that[1].
And what if a package or drone falls from such a height?
I think the concept on its face is flawed, but then again, this exists[2].
> But then how do you deliver to the upper floors of vertical buildings?
Maybe asking the obvious, do you need to? Why not drop the package downstairs, people can use the elevator like normal people? Assuming there is some sort of hand-off with identification.
Many parts of Europe solved it in a more low-tech way: street-side parcel lockers unlocked with your phone. Massively reduces delivery cost (i.e., one driver can deliver far more packages per hour), is pretty convenient and safe (no packages left unattended), and best of all, doesn't require a fleet of UAVs.
You can pretty naturally extend this once you have self-driving vans.
I think Amazon has a proprietary version of this in some parts of the US, but at least where I live, the lockers are a car drive away, which defeats the purpose.
The last tower I worked in wasn't some really big tower (only about 16 stories) but in the lobby near the security booth there was a set of shelves operated by a food delivery company. Every day there would be a few restaurants listed, you'd place your order, and they'd deliver everyone's food around noon to the shelves. You'd just go down and grab your meal.
Seemed to work well enough for the times I used it. Honestly though I really valued the time to take a break and go for a walk and have lunch away from sitting at my desk.
Japan too, convenience stores are everywhere, packages go to lockers in the convenience store, unlock with phone app.
(Of course you can still choose to have them delivered to your door, but I find the delivery people don't ring the doorbell and then mark the delivery as missed, even with instructions to leave the package in front of the door. But that's a separate issue.)
The chinese too, afaik, in shanghai drones deliver parcels in specific parcel stations. Flying drones delivering stuff (through the windows?) to upper floors of buildings sounds like sth between scifi and madness right now. Having specific pickup locations solves a lot of problems like the ones here, as drones can just have to follow specific, predetermined routes that can be more easily monitored, instead of having to go to some random, different address.
Have you ever been inside a tall building? How are you thinking a drone would deliver to the upper floors of vertical buildings? The windows don’t open. There are occasional balconies or terraces, but these are more the exception than the rule, especially for “hungry office workers in a Shenzhen skyscraper.”
Residential buildings usually have operable windows (and often balconies). My condo building is only 17 stories tall, but my windows open all the way. On the other hand, it's an old building and there might be new rules for new buildings, since for those I usually only see the windows open a little.
Still it would be silly to deliver through the window. The rooftop might make more sense (can just drop off package and not accessible to random people on the street).
Apple bought them, took it down from the web, then quietly open-sourced it a few years later. They tried to make it popular, ran a conference for it, but the adoption was too minor for Apple to care afterwards.
It's still maintained by a sizable team at Apple, GH stats show that the activity is much lower now than it was 3 years ago, but there're about 10 people that contribute on a steady regular basis, which is honestly better than 99% of open source projects out there.
The only reason is Apple. They liked the product that was released in 2013 so much they bought the whole company, and all other FoundationDB users were abandoned and were forced to drop it.
Who would trust a database that can be yanked out of you at any moment? Though a lot of products have license terms like this only a handful were ever discontinued so abruptly. It's under Apache license now but the trust is not coming back.
`Arc`s show up all over the place specifically in async code that targets Tokio runtime running in multithreaded mode. Mostly this is because `tokio::spawn` requires `Future`s to be `Send + 'static`, and this function is a building block of most libraries and frameworks built on top of Tokio.
If you use Rust for web server backend code then yes, you see `Arc`s everywhere. Otherwise their use is pretty rare, even in large projects. Rust is somewhat unique in that regard, because most Rust code that is written is not really a web backend code.
> `Arc`s show up all over the place specifically in async code that targets Tokio runtime running in multithreaded mode. Mostly this is because `tokio::spawn` requires `Future`s to be `Send + 'static`, and this function is a building block of most libraries and frameworks built on top of Tokio.
To some extent this is unavoidable. Non-'static lifetimes correspond (roughly) to a location on the program stack. Since a Future that suspends can't reasonably stay on the stack it can't have a lifetime other than 'static. Once it has to be 'static, it can't borrow anything (that's not itself 'static), so you either have to Copy your data or Rc/Arc it. This, btw, is why even tokio's spawn_local has a 'static bound on the Future.
It would be nice if it were ergonomic for library authors to push the decision about whether to use Rc<RefCell<T>> or Arc<Mutex<T>> (which are non-threadsafe and threadsafe variants of the same underlying concept) to the library consumer.
Blocking on an asynchronous task and waiting for it to finish is fundamentally a different operation than spawning an asynchronous operation and returning to the caller to execute entirely different code.
My go-to use case for modern Perl is to be the default program instead of sed. Sed regex support is abysmal and the same command line flags behave differently between BSD (and macOS) and GNU versions, in particular the `-i` for doing replacements - the number one use case for the program. So, this means that many shell one-liners and small scripts don't really work the same way on macOS and on Linux, and it's pretty annoying.
Perl is straight up better. You need to remember one word: pie - for it's command line options, and now you can do:
First of all, it woks the same way across platforms.
Second, you get all sorts of goodies: named capture groups, lookahead and lookbehind matching, unicode, you can write multiline regexes using extended syntax if you do something complicated.
And finally, if your shell script needs some logic: functions, ifs, or loops, Perl is straight up better than Bash. Some of you will say "I'll do it in Python", and I agree. But if your script is mostly calling other tools like git, find, make, etc, then Perl like Bash can just call them in backticks instead of wrapping things into arrays and strings. It just reads better.
BTW Ruby can do it, too, so it's another good option.
Somewhat related. At some point around 15 years ago I needed to work with large images in Java, and at least at the time the language used 32-bit integers for array sizes and indices. My image data was about 30 gigs in size, and despite having enough RAM and running a 64-bit OS and JVM I couldn't fit image data into s ingle array.
This multi-memory setup reminds me of my array juggling I had to do back then. While intellectually challenging it was not fun at all.
TBF it does happen to other package managers, too. There were similar attacks on PyPI and Rubygems (and maybe others). However, since npm is the largest one and has the most packages released, updated, and downloaded, it became the primary target. Similar to how computer viruses used to target Windows first and foremost due to its popularity.
Also, smaller package managers tend to learn from these attacks on npm, and by the time the malware authors try to use similar types of attacks on them the registries already have mitigations in place.
Trusted Publishing is a marketing term—a fancy name for OIDC support and temporary auth token issuance. It delegates authenticating the uploader to their identity provider, nothing more.
In a very real sense, it shifts responsibility to someone else. For example, if the uploader was using Google as their identity provider and their Google account was popped, the attacker would be able to impersonate the uploader. So I wouldn’t describe it as establishing a strong trust relationship with the uploader.
It only meaningfully improves the security of the NPM ecosystem if (a) everyone is forced to sign packages and (b) identity providers require more secure authentication methods with as hardware tokens or passkeys.
Trusted publishing helps with tracking down how something got compromised after compromise. It doesn't do anything to protect against compromise except for using time-limited credentials but that only makes the window smaller. It doesn't make compromise impossible
My semi-conspiracy theory is that the success of Rust is partially due to BigTech companies searching for a "legally-safe" alternative to Java.
The multi-year Google vs Oracle lawsuit put the likes of Amazon and Facebook to unease. And meanwhile there was this safe and performant language with no strings attached under a nice Apache license. They quickly made a Foundation around it as a 501(c)(6) - trade association, and not a "public good"-kind of a non-profit. This essentially means that as long as you're a member and pay the fees you won't be sued - exactly what all these companies wanted. So now they all keep up the funding and employ some of the compiler developers to keep the lights on for next 20 years or longer.
The fact that the language itself is really good for what they need it for is obviously the major reason why they support it, but the legal side of things definitely helped with adoption.
I'm not sure where things fall on your timeline, but in case you missed it, Amazon has their own Java distribution called Corretto. It was first publicly released in 2018:
This conspiracy theory would explain not only success of Rust, but also Go language and C#/.NET, and any other Java competitor.
I'd say it's 90% because of Oracle and its lawyer-driven business, and 10% because the language is just ugly, and existing libraries are super-ugly and unreadable, with all these Factories and AbstractFactories, and all design patterns forced like a religion whether they're useful or not in a specific context.
reply