> it's clear the author thinks his' is the moral stance
If you don't think your moral stance is the correct one - then why aren't you changing your moral stance? Why do you have one at all?
It's ok to have strong opinions on morality, and it's cool to live by them, and good to talk about them. I don't happen to completely agree with the author, but I can respect a belief in one's own considered opinion, and the right to express it. No one is being harmed by the author's article.
For example, I have a "strong" moral opinion, which makes many people angry to hear: I don't vote for politicians who arm and enable genocide.
In America, that makes me weird, or worse. I still believe I'm right, and I still talk about it. I firmly believe that cutting out anyone who collaborates on genocide and vetoes ceasefires is the only morally correct move, and happy to talk about why I think that's not just justified and rational but also simply your bare minimum duty as a human being.
That doesn't mean I can't acknowledge that other people feel differently, or that I can't understand where they're coming from with some level of empathy. But it also doesn't mean I have to hang around them. I generally choose not to - genocide enablers squick me out.
The author even explicitly acknowledged that other people have different moral views:
> I will not change my morals or ethics to suit someone else, nor do I expect other people to change theirs.
Along with self awareness and reasonable doubt:
> Does that make me unreasonable? Maybe?
On top of which, the whole diatribe is presented as a "random musing", rather than a demand for you to think differently.
I have difficulty trusting this. There are plenty of videos online of LLMs making up stuff like "I just ate a hot dog, is there mustard around my mouth?" "No, everything is clean" while there is a big yellow stain om the guy's face
The problem is using a language model to assess images.
Probably 80% of "LLM's are below expectation" complaints (from the general population) involves some form of image analyses.
Image tokenization is hard because unlike language tokenization, where every token is extremely dense with meaning, image tokens tends to be meaningless or irrelevant but are processed all the same.
Give an SOTA LLM a picture of toothpicks and ask it to move one to make a square, and it will probably struggle and fumble it. But give a mid-size LLM from 2 years ago the same problem in verbal form, and it will nail it almost every time.
That takeaway is, do everything you can to avoid having the LLM need to rely on images for the answer.
Like coding, creating images or text, maybe the alternative of doing it yourself is too easy or enjoyable for you. Don't expect that will be true for everyone.
I guess it's storage, sensors and microwave links. On one corner you can see a concrete pad where a small boat can land unseen from the mainland. There are some official helicopter flyby videos but all of them fail to capture this one particular side of the island.
Are there public tournaments of games like Pokemon where contestants have to compete with eachother using a specific class of algorithms (e.g., logic programming, neural nets, linear programming, etc.)?
Don't worry, once enough people come back, they'll roll back in the ads and the intrusive performance-killing features and the cycle will repeat all over again
A fundamental problem with this is that "8" is two different releases (8.0 and 8.1), "10" is about 9 different releases, and "11" is three different releases so far (21H2, 22H2, and 24H2). It doesn't make much sense to lump all of them together because they share the same marketing name; technically there's no difference between going from 8.0 to 8.1 or from 22H2 to 24H2 and going from Vista to 7 or 10 20H1 to 11 21H2
10 was bad 11 is a little better but no enough.
With win10 they started with more annoying ads and the start menu with apps and the click bait news in the start menu
It was, eventually. In the beginning 10 was literally just Windows 8.1 (it even ran the same NT6 kernel) but with the classic UI slapped back on. They called it 10 to get away from the Windows 8 branding that everyone hated.
I recall it being pretty mediocre at release, just a reskinned 8.1. 10 started to come into its own much later after NT10
Aside from the start menu no, not really. Windows 8 is the most performant operating system. No laggy animations (thanks to DirectUI), fast boot time, especially fast on older systems. Windows 10 started the whole lagfest.
exactly! I don't understand why people hated it so much.
It was snappy, clean OS. I've always thought it was better than Win7.
Of course, absent of start menu was terrible choice. And I meant 8.1, not 8.
"aside from the start menu" is one hell of a caveat. When you screw up one of the main UI elements as badly as they did, it really drags the whole experience down.
Well most people just press the Windows key and type to open a program which works exactly the same on Win8. And personally I loved the start screen. And how often do you really need the start menu?
That's the most brain dead take I've seen in a while. Yes, forget about start menu and lets just search everything or use giant pictorials designed for 'blind' people.
Windows 8 was ultra stable. I've seen uptime well over multiple years on it. The original UX was beyond awful and 8.1 made it ok but the core of the OS was solid.
I mean, apart from killing the start button and all the touch first applications, windows 8 felt really satisfying to me by eliminating transparency effects and having simpler, clearer window decorations. I hate the transparency effects in windows 7, and performance was improved in Win 8.
Maybe Windows 12 will be the promised "last Windows" which 10 was supposed to be.
I'd love to know the exec who ordered Windows 11. It stinks of "I need a product on my resume that I launched because being Windows 10 "maintainer" sounds so pathetic on a resume."
Feel free to post a project of yours where you gave a bunch of prompts to an LLM and it produced a working application written in assembly without you having to check for anything
This is why I always ignore these headlines until I see the change firsthand. In this case it wasn't even an article, only a brief forum comment, for a topic as complex as spam protection. Might not be an A/B test, could just be someone with a low-trust profile (eg Arch Linux ipv6 in Singapore with multiple Gmails).
MPEG-2 TS is a container. H.264 is a coding specification. They are totally different things.
One can find MPEG-2 TS in surprising places (see: DOCSIS encapsulating Ethernet frames into TS packets).
If I had to guess why MPEG-2 TS, it'd probably be the for the fact it's a well-supported streaming format in both hardware and software. If you tried using QuickTime or MPEG-4 containers, you'd have to rely on hacks like ensuring the moov atom preceeds mdat.
Matroska may be worth considering (especially the subset used by WebM to make it stream-friendly and quicker to seek), but no idea how widespread hardware support is for (de)muxing that.
Before ProRes, we captured HD content at 100Mbps MPEG2 video with PCM audio wrapped in a 302m stream that were muxed together as an MP2TS wrapper. The 302m made it even more difficult as not all MP2TS tools could do it correctly, and some would not allow for custom Program stream IDs and needed to be remuxed by other tools allow for custom PIDs as a post process.
But seeing how many uses people came up with for using MP2TS just shows it's flexibility and resilience.
I don't think MKV is better suited for low-latency streaming production (as opposed to consumption) than MP4. That's really more of the domain of MPEG-TS, RTP etc., and presumably this is a reliable transport alternative to that.
HLS, MPEG-DASH etc. do successfully work around much of that, but they're really mostly that – workarounds to present stream-like semantics over an HTTP + CDN based delivery mechanism.
There are significant gaps on the production/distribution side of things, i.e., everything that happens before the CDN (and for very low latency even beyond), and I suppose this is an attempt at filling those.
Sure, but there are a lot of media applicances that don't really have upgradeable software. I suppose it can be pretty useful to just (un)wrap MoQ and feed the result over a local interface into something that just expects M2TS and vice versa.
MPEG-TS is used to contain h264 chunks for HLS. MPEG-DASH and the new CMAF standard use fMP4 containers instead. My personal take is that Media over QUIC (MoQ) should support both.
The nice thing about fMP4 is that it's supported by both HLS and MPEG-DASH, so you can save yourself the effort of duplicating all data at the CDN level (or using a CDN that can just-in-time assemble fMP4 and M2TS files from the same underlying source).
I don’t think it’s unfounded. Media codecs have been one of the top sources for serious vulnerabilities. The code is incredibly complex, and takes complex input from untrusted sources.
Decoders are one of the best places for rust because they are both performance critical and security critical.
JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it. And the apps that did utilise the C based libjxl ended up hit with vulnerabilities in it.
> JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it.
This is extremely misleading. Before they even started work on the Rust-based decoder, experimental JPEG XL support was added to Chrome and Firefox using the reference C++ implementation. Chrome later removed this support for very dubious claims of lack of interest and improvement over previous generation of codecs.
Around that time, Safari shipped JPEG XL support in production, still without the Rust implementation. So the assertion no one wanted to touch it is plain false.
It was actually Mozilla who, a long time after stating they were ambivalent on JPEG XL, brought up memory safety as a major consideration, for the very first time. That’s when the work on the Rust implementation started.
Since the format continued to be more and more supported and talked about, it’s hard to say what exactly were the factors which made Google reconsider their stance. The notion that somehow everyone was super worried about memory safety from the very beginning, and once the JXL team fixed that, everyone was happy to embrace it, seems to come up a lot lately, but it’s terribly distorted and simply not true.
Not necessarily. What’s annoying is these low-effort posts that bring nothing. In some contexts the discussion is worth having, but we can do better than "it’s bad because it’s not in my pet language" groupthink.
That codecs should be written in safer languages given that they usually process untrusted files. There have been a number of serious hacks from file parsing bugs due to them being written in unsafe languages.
There's literally a DSL designed for this purpose (Wuffs) so it would be interesting to hear why they didn't use it.
There's an order of magnitude difference in speed requirements between file format parsing and image decoding, then another order of magnitude difference to video decoding. Even rav1d reuses dav1d's assembly (most of the actual runtime) to approach its speed.
They say it is 5% slower. That's close enough. I know they say it isn't but in reality that speed difference is just going to be used as an excuse by the anti-Rust crowd.
The people who write DSLs for video codec asm, or who claim that it's fine to use intrinsics or X higher-level language and it will still be fast enough to be usable, are simply wrong and have never been able to demonstrate otherwise.
Having said that I do think you could write a DSL to generate safe performant asm for a video codec. Just not a platform-independent one. It would still have to be asm.
It sounds like your second statement contradicts your first. But also, WUFFS exists and it looks like the Google Chrome GIF decoder ships in it: https://github.com/google/wuffs
And? It's common knowledge that the "reference" or "research" version of any codec is always quite high level to get development going and actually produce a working bitstream
So a project should change its name because when it will be production ready 6 years from now the 1% of the 1% of the 1% will think for 1 microsecond about a piece of news from today?
Hollywood retitles movies based on books all the time[1], for the silliest of reasons ("Sorcerer's Stone" was contemporaneous to LOTR too); so given there's precedent, it follows that those wanting to retain the original title from the books should defend their position.
Potentially... supposing the criminal investigation into this uncovers a hitherto unknown organ harvesting scheme operating within the global music records industry; the subsequent police dragnet implicates significant proportion of the world's music stars and record labels and generates continual major headlines and criminal convictions - with all their lurid details - all for multiple decades from now on.
It's quite ridiculous when I put it that way, but this is basically the same thing as Epstein's network, just with a different crime; and Epstein was already in the news almost 20 years ago from his first conviction.
...so back in 2009, back when everyone was building their own social-network websites and online dating services, and supposing your real-name was also Epstein, so you called it "EpsteinLoveIsland.com" - would you have changed the name back then?
reply