Linux already has its own binary executable format, ELF (that you could just statically link, if you wanted to bundle everything).
Also the usual way to indicate that some file is executable on linux systems is just through an execute bit, not through an extension.
But the discussion here is more about how to package properly an application (for updates, app centralized management etc,) than how to deliver an executable on linux.
Transpilation is here a necessary step to test the application because e.g. his browser won't be able to parse raw TypeScript code.
Typechecking is not: the browser doesn't care about it, it's mainly to help the developer verify its code.
So to speed-up the build during development (to have faster iterations) the idea is often to make the building process only about the build by removing "unnecessary" steps like type-checking from it, while having a separate linting / typechecking etc. process, which could even run in parallel - but not be necessary to be able to test the application.
This is often done by using tools like a bundler (e.g. esbuild) or a transpiler (babel, swc) to erase the types without checking them in your bundling process.
Yes basically, it's not the same dev yet sway is heavily inspired by i3 and works with i3 config files.
As you wrote i3 is x11-only and sway is wayland.
I always had an issue with that sentence (and I heard it a lot).
Why would experienced software developers always come with a solution worse in "every conceivable way" when implementing logic answering a problem they're having, which would have the huge advantage of being tailored for their own needs?
I'm more of a library developer than an application one but I've seen that many JS webdevs have an aversion toward trying things themselves - instead always going for the most huge/"starred" dependency when they can. I'm not sure the impact of this philosophy is always better for a project's health than the total opposite where you would just re-invent your own wheel.
I do have seen multiple attempts at doing a specific homemade architecture that worked out well for some applications with very specific needs even 10 years later (For example I'm thinking about a 500k+ LOC JS webapp - not intended to be accessed on a desktop browser, but that's not the only successful long-lived JS project I know with their own archi).
And I guess a lot of webapps do have their own specific needs where the "default framework" solution leads to some inefficiencies or hard-to-maintain / understand mess.
Presumably this for now has only been seen for a specific tv client API that yt-dlp use and not all youtube videos (well, https://github.com/yuliskov/SmartTube/issues/4444 also saw it for "members-only" videos but again not all videos).
---
Also I suppose you make a reference to software DRM like Widevine L3 vs L1 (same thing for PlayReady SL2000 vs SL3000) which is not exactly Firefox vs Chrome. Firefox has even be known to work on the availability of hardware DRM on windows right now, (through the Media Foundation API I think?).
In the worst scenarios seen right now for example seen on services like Netflix, would be to only have lower qualities (e.g. 480p max) on browsers with only Software DRM available (like firefox) and encrypt better qualities with keys only available when there is hardware DRM available.
Though I'm not sure YouTube would go that far for now? Netflix, Amazon and such have contracts with right-holders stating those protections as a requirement, but YouTube does not have (IMO thankfully) the same kind of relation and contract with "Youtubers".
I think that what YouTube wants to do for now is to greatly lower the amount of people not watching contents through its website/app (and thus not seeing ads). I would even think that this is mostly not about yt-dlp users, but more the huge amount of people relying on some Youtube-to-mp3 website or similar accessible tools.
Here enforcing software DRM would be enough to at least temporarily break all those tools and force those users to go back on the platform I guess, and maybe you can also sue some tools' developers once there is an "encryption breaking"-mechanism embedded in it (IANAL)?
> Though I'm not sure YouTube would go that far for now? Netflix, Amazon and such have contracts with right-holders stating those protections as a requirement, but YouTube does not have (IMO thankfully) the same kind of relation and contract with "Youtubers".
It does with the music labels, which is why said labels sued various YouTube downloaders for bypassing a technical protection measure in regards to the existing rolling cypher (but reading between the lines I suspect the labels intention was actually to lose that case, and then take that judgement to YouTube to show that they were in breach of the contract that required them to include some form of technical protection measure and hence adopt Widevine on all music streams).
Not him but because your answer surprised me I chose to reply: at 34 it is also something I always wondered.
Becoming obese always seemed a little extreme to me and I fail to imagine how someone could reach that state without the accordingly extreme food-related habits - though maybe I'm just lucky to have the "right" metabolism and thus cannot relate.
Though even if obesity was always linked to eating disorders, I understand that "just stop" is not an appropriate response to that issue.
A particularly ugly but useful feature of "const enum" (sadly, the "const" flavor of enums are not referred to in this documentation), is that it's the only way to declare a compile-time constant in TypeScript.
e.g. for "development" vs "production" environments, you could write a declaration file for each of those envs as such:
// some_file.ts
if (ENVIRONMENT.CURRENT_ENV === ENVIRONMENT.DEV) {
// do something for dev builds
}
It will be replaced by TypeScript at compile-time and most minifiers will then be able to remove the corresponding now-dead code when not in the right env.
This is however mainly useful when you're a library developer, as you may not have any "bundler" dependency or any such complex tool able to do that task.
Here, the alternative of bringing a complex dependency just to be able to replace some constants is not worth its cost (in terms of maintenance, security, simplicity etc.), so even if `const enum`s may seem poorly-adapted, they are actually a good enough solution which just works.
I read the README.md of the project but I'm still not sure: What's the expected usage of this? How does the outputed WASM code then interacts with a runtime (and with which, is it intended to be a tool compatible with browsers and other WASM runtimes or is it only compatible with a runtime linked to the project)?
Somewhat linked questions: How does it react if it encounters e.g. web APIs inside the JavaScript code or other global identifiers only defined in some environment (e.g. a recent browser, Node.js etc.)?
Or if it's not intended for those environments, how are you supposed to do I/O when using this?
These are very good questions, I'll respond here, but I'll also add more info to the README. This project is mainly targeting WebAssembly usage on the server, cause I think it makes little sense to run JavaScript in WebAssembly in JavaScript (although time will tell, maybe it will be useful for sandboxing frontend plugins?). Regardless if it's running in the browser or a backend runtime like WasmTime or WasmEdge, at the moment running JavaScript inside WebAssembly is not ideal. You either have to compile a JS engine like V8 or SpiderMonkey to WASM and then use it to run your script or you have to settle for an "almost JavaScript" language like AssemblyScript. This is a limiting factor for running server workloads. For example Fastly uses SpiderMonkey for their WASM workers, but it means that each instance uses 5-10MBs of memory even for a hello world. Shopify, on the other hand, uses WASM for customizing server side of their shops, and they decided they only allow WASM binaries up to 250KBs, which is a no-go for embedding any interpreter. Thus their "blessed" language is AssemblyScript. They outline reasons for that here: https://shopify.engineering/shopify-webassembly
This is all due to a fact that historically WASM was a very simple runtime. It was relatively easy to compile C code to WASM, just like you compile C code to machine code, but even though a WebAssembly is a kind of interpreter by itself, it wasn't easy to interpret higher level languages on top of it.
With new proposals being standardized, like garbage collection support or exception handling support, WebAssembly becomes much more powerful interpreter, with stuff like structs, arrays, function references etc.
Jaws leverages that fact translating JS code to WASM code in a way that WASM interprets the resulting code, without the need of a JS engine like SpiderMonkey. In practice it mainly means that a binary generated by Jaws will be probably under 50KBs vs 10MBs when you compile SpiderMonkey to WASM and run your script on top of that. Memory usage will be also significantly lower. For companies like Fastly this would mean orders of magnitude lower memory usage and thus server costs. For companies like Shopify it would mean they could leverage JavaScript code already available (think NPM packkages) and JavaScript ecosystem for people writing plugins for Shopify's backend.
> is it intended to be a tool compatible with browsers and other WASM runtimes or is it only compatible with a runtime linked to the project
The only runtime the project uses is WebAssembly. The generated code is mostly 3k lines of WAT code form this file: https://github.com/drogus/jaws/blob/main/src/wat/template.wa... and whatever your JS code is translated to. For example for a very simple program like "console.log('foo')" the entire "generated" part is this: https://gist.github.com/drogus/1c49c25ed0b14804b2f27e10d2a79..., which more or less prepares an argument (with new_static_string) and then calls console.log. Right now I need a bit of glue code on the host, but eventually it will be possible to execute such a binary with any runtime that supports WASIp2, WASM GC and exception handling proposals.
> Somewhat linked questions: How does it react if it encounters e.g. web APIs inside the JavaScript code or other global identifiers only defined in some environment (e.g. a recent browser, Node.js etc.)? Or if it's not intended for those environments, how are you supposed to do I/O when using this?
None of this is implemented yet, but I can tell you how it will work. I plan to support Node.js APIs through WASI. WASI is a standard for communicating between WASM programs and the outside world. For example WASI defines a standard set of functions you can use to send an HTTP request, or write to STDOUT, or read/write to a file. So when I get to APIs like `fetch` or `fs`, it should work with any runtime that supports WASI preview2. Browsers could also be supported with polyfills, but in this case I/O support is more custom. Like, if you decide you allow WASM programs to write or read files, you would have to provide a mechanism to do that, for example save files to localStorage or an SQLite database compiled to WASM (or I guess even send them to S3 or something along the lines).
They probably don't want to license them globally, because the expected usage is low. But surely this could be taken into account in the contract / negotiation. Anyway I guess I'm just not in the target audience. But that's what MPV is great for, it allows you to tweak it for that 0.1% use-case.
I think it's also partially an issue with video + audio being paired by region.
AFAIK, the video you are being served is always based by the geolocation and what video was licensed for that. E.g. in a French version of a movie, text in the movie may have been localized into french inside the video. Additionaly there might be additional/missing scenes in the localized version to get the desired age ratings in that market.
The audio is then synced to that version of the video. That means that e.g. the French audio produced for the US video is not 1:1 the same audio as the French audio for the German video.
So that takes it beyond a licensing issue, and would mean additional effort to produce compatible audio tracks for content that they may only have streaming rights for temporarily. For content native to the streaming service they usually put that effort in.
But the discussion here is more about how to package properly an application (for updates, app centralized management etc,) than how to deliver an executable on linux.