Well they certainly gained dominance by being the best and I would say they still are the best. But maybe there was some competitor that could have usurped them by being even better if not for their anticompetitive tactics. I wouldn't put money against that...
It's definitely not as simple as you're suggesting. PDF viewers are not vector graphics editors so they'd have to implement the whole intersection algorithms, and even though PDFs don't reflow they can still have text so now you need to figure out if you delete "is" from "this is hard" you need to calculate where "hard" is.
I use YouTube Music and it definitely does work but yeah it weighs songs you've already said you like way too heavily and generally seems way worse at discovering similar music than Last.fm or Pandora from over a decade ago. (If anything I remember Pandora being too good at finding similar songs - the playlist would end up almost monotonic because it found such similar music.)
Fortunately they do have a "Discover playlist" that completely excludes music you've heard before. Unfortunately that's all you get. No way to e.g. say "play me reggae I haven't heard before", and it's only updated once a week.
So yeah... kinda shit. But still better than the alternative which as far as I remember from the 90s is to only listen to extremely well-known bands and find good news music like once a year.
I disagree. Think about every time you use a service (website, email, etc.) you've used before via a network you don't trust (e.g. free WiFi).
On the other hand providing the option may give a false sense of security. I think the main reason SSH isn't MitM'd all over the place is it's a pretty niche service and very often you do have a separate authentication method by sending your public key over HTTPS.
When I use a service over TLS on a network I don't trust, the premise is that I only will trust the connection if it has a certificate from a handful of companies trusted by the people who wrote the software I'm using (my browser/client and/or my operating system) to only issue said certificates to people who are supposed to have them (which these days is increasingly defined to be "who are in control of the DNS for the domain name at a global level", for better or worse, not that everyone wants to admit that).
But like, no: the free Wi-Fi I'm using can't, in fact, MITM the encryption used by my connection... it CAN do a bunch of other shitty things to me that undermine not only my privacy but even undermine many of the things people expect to be covered by privacy (using traffic analysis on the size, timing, or destination of the packets that I'm sending), but the encryption itself isn't subject to the failure mode of SSH.
Establishing the initial exchange of crypto key material can be.
That's where certificates are important because they add identity and prevent spoofing.
With TOFU, if the first use is on an insecure network, this exchange is jeopardized. And in this case, the encryption is not with the intended partner and thus does not need to be attacked.
> I disagree. Think about every time you use a service (website, email, etc.) you've used before via a network you don't trust (e.g. free WiFi).
Hm? The reason I do use those services over a network I don't trust is because they're wrapped in authenticated, encrypted channels. The authenticated encryption happens at a layer above the network because I don't trust the network.
But isn't that exactly the previous posters point? Free WiFI someone can just MITM your connection, you would never know and you think its encrypted. Its the worst possible outcome. At least when there's no encryption browsers can tell the user to be careful.
Funny thing I found when I gave up trying to find documentation and read the LLVM source code (seems to be what happened to the author too!): there are actually five components of the triple, not four.
I can't remember what the fifth one is, but yeah... insane system.
Thanks for writing this up! I wonder if anyone will ever come up with something more sensible.
There are up to 7 components in a triple, but not all are used at once, the general format is:
<machine>-<vendor>-<kernel>-<libc?><abi?><fabi?>
But there's also <obj>, see below.
Note that there are both canonical and non-canonical triples in use. Canonical triples are output by `config.guess` or `config.sub`; non-canonical triples are input to `config.sub` and used as prefixes for commands.
The <machine> field (1st) is what you're running on, and on some systems it includes a version number of sorts. Most 64-bit vs 32-bit differences go here, except if the runtime differs from what is natural (commonly "32-bit pointers even though the CPU is in 64-bit mode"), which goes in <abi> instead. Historically, "arm" and "mips" have been a mess here, but that has largely been fixed, in large part as a side-effect of Debian multiarch (whose triples only have to differ from GNU triples in that they canonicalize i[34567]86 to i386, but you should use dpkg-architecture to do the conversion for sanity).
The <vendor> field (2nd) is not very useful these days. It defaults to "unknown" but as of a few years ago "pc" is used instead on x86 (this means that the canonical triple can change, but this hasn't been catastrophic since you should almost always use the non-canonical triple except when pattern-matching, and when pattern-matching you should usually ignore this field anyway).
The <kernel> field (3rd) is pretty obvious when it's called that, but it's often called <os> instead since "linux" is an oddity for regularly having a <libc> component that differs. On many systems it includes version data (again, Linux is the oddity for having a stable syscall API/ABI). One notable exception: if a GNU userland is used on BSD/Solaris system, a "k" is prepended. "none" is often used for freestanding/embedded compilation, but see <obj>.
The <libc> field (main part of the 4th) is usually absent on non-Linux systems, but mandatory for "linux". If it is absent, the dash after the kernel is usually removed, except if there are ABI components. Note that "gnu" can be both a kernel (Hurd) and a libc (glibc). Android uses "android" here, so maybe <libc> is a bit of a misnomer (it's not "bionic") - maybe <userland>?
<abi>, if present, means you aren't doing the historical default for the platform specified by the main fields. Other than "eabi" for ARM, most of this is for "use 32-bit pointers but 64-bit registers".
<fabi> can be "hf" for 32-bit ARM systems that actually support floats in hardware. I don't think I've seen anything else, though I admit the main reason I separately document this from <abi> is because of how Debian's architecture puts it elsewhere.
<obj> is the object file format, usually "aout", "coff", or "elf". It can be appended to the kernel field (but before the kernel version number), or replace it if "none", or it can go in the <abi> field.
The components are arch-vendor-os-environment-objectformat.
It's absolutely full of special cases and hacks. Really at this point I think the only sane option is an explicit list of fixed strings. I think Rust does that.
You're not really contradicting o11c here; what LLVM calls "environment" is a mixture of what they called libc/abi/fabi. There's also what LLVM calls "subarch" to distinguish between different architectures that may be relevant (e.g., i386 is not the same as i686, although LLVM doesn't record this difference since it's generally less interested in targeting old hardware), and there's also OS version numbers that may or may not be relevant.
The underlying problem with target triples is that architecture-vendor-system isn't sufficient to uniquely describe the relevant details for specifying a toolchain, so the necessary extra information has been somewhat haphazardly added to the format. On top of that, since the relevance of some of the information is questionable for some tasks (especially the vendor field), different projects have chosen not to care about subtle differences, so the normalization of a triple is different between different projects.
LLVM's definition is not more or less correct than gcc's here, nor are these the only definitions floating around.
Hm, looking to see if the vendor field is actually meaningful ... I see some stuff for m68k and mips and sysv targets ... some of it working around pre-standard vendor C implementations
Ah, I found a modern one:
i[3456789]86-w64-mingw* does not use winsup
i[3456789]86-*-mingw* with other vendors does use winsup
There are probably more; this is embedded in all sorts of random configure scripts and it is very not-greppable.
Seller-side here. Amazon combine my author page, with that of A.A. Milne. Some of my products show up under the deceased author, some of his under mine. Reviews for one particular product are combined.
My seller ID is separate, my last name is also Milne, but my first is James.
He wrote a book called "The Red House Mystery", I wrote an homage to it because I am related to the man, called "Red House". Different products, with different ISBNs.
Combined reviews. [0]
That's not exactly a fair process for customers - and no, I can't get them uncombined. I've been trying for years. But if the seller can't get rid of something completely misleading, that seems to have been caused by a very badly automated process, then there are processes at Amazon that cause problems.
I've only ever left one bad review on Amazon. Chopsticks, they came bound together with some sticky tape. Sticky tape left a very sticky area just where your hands go that I was unable to get off despite a lot of effort scrubbing, washing, and so on. I left a polite constructive review saying they were good chopsticks but watch out for this stickiness issue. My review was declined by Amazon on the grounds it didn't meet their "community guidelines" (without elaborating further on which rule I'd supposedly broken).
Ok, well I've left nine 1-star and many other 2 or more star reviews and none of them have been removed for any reason, so I would say you got unlucky and that I stand by my comment that Amazon don't do anything like automatically redirecting all 1-star reviews to customer service.
I bought one to get sticker residue off my windshield, but it's proven useful many times since.
Mind, considering how well it removes glue, I wouldn't stick anything that was touched by it in my mouth... but may be okay for the hand end of your chopsticks.
Orange oil works wonders. It's explicitly not food safe, but you get that stuff on your hand every time you peel an orange and it's also present in juice. Just rinse them afterwards and wear gloves.
I recommend isopropyl alcohol. It’s cheap, versatile and works like a charm for most of your cleaning jobs. Way safer and cheaper than sprays and "super-do-that-thing-4000". No offense to the sprayers.
The community guidelines rejection is such BS. I've done thousands of Amazon reviews and get about 1% rejection rate, and it's always baffling as to the cause. You develop superstition over time over what is the cause. I avoid certain words (sexual, violence, mention of other brands), blur our barcodes, etc. "Sticky" would trigger my "uh oh, sounds sexual" alarm and I'd word it something like "tape around chopsticks left adhesive residue". Like I said, superstition.
Amazon is known for suppressing negative reviews, there are many reports about it. Not sure why the grandparent comment is claiming the contrary - not doing the automatic redirect maybe, but they do remove or just not accept negative reviews.
They absolutely do, it's personally happened to me. My review was rejected because I simply listed what items were included in the box, one of them being a card that offered a bribe for a positive review.
Every review I left for Amazon products (Amazon EU) got rejected until it was diluted into nothing. The explanation was always vague, listing a dozen possible reasons, none of which fit what I wrote.
On non-Amazon products it's a coin toss for negative reviews. Many are published, some are not. Can't explain why.
Google is not better, negative reviews I leave on Maps are published very selectively. Maybe big-tech found a way to monetize this too. I know sites like Yelp are more or less an extortion business where you pay to get negative reviews wiped.
Neither does Temu. They're misrepresenting what Temu does, at least in my experience.
If you choose a star rating below five, Temu asks if you'd like to request a refund or seek other assistance. The one time I said yes -- it was a keyboard where a shift key wouldn't trigger consistently at the peculiar angle that my typing style hit it at -- it immediately gave me a 100% refund and said just keep it.
But I've left other low-star rating without trouble. The refund/assistance suggestion is an entirely optional sidetrack.
I've never (to my knowledge) had a review on Amazon rejected, and I've left very some negative reviews, including when I received counterfeit items.
I always thought the review scams on Amazon were more driven by the third-party sellers doing stuff like listing takeover, astroturfing reviews, bribing customers for good reviews, etc., but maybe I'm wrong. I have personally received multiple offers from third-party sellers of incentives to leave good reviews.
reply