alexvitkov

10 miesięcy temudiscuss

API/SSH keys can easily be swapped, it's more hassle than it's worth. Be glad they didn't choose to spread the payload of one of the 100 ransomware groups with affiliate programs.

alexvitkov

10 miesięcy temudiscuss

Most language users will follow the "spirit" of the language - e.g. Bill is against package managers, people who use his language mostly agree with his ideas, and there's not a huge standard Odin package manager.

I rather appreciate that C and C++ don't have a default package manager that took over - yes, integrating libraries is a bit more difficult, but we also have a lot of small, self-contained libraries that just "do the thing" without pulling in a library that does colored text for logging, which pulls in tokio, which pulls in mio, which pulls in wasi, which pulls in serde, which is insane.

alexvitkov

10 miesięcy temudiscuss

"Vendoring step" You cannot make this shit up.

You're providing a library. That library has dependencies (although it shouldn't). You've written that library to work against a specific version of those dependencies. Vendoring these dependencies means shipping them with your library, and not relying on your user, or even worse, their package manager to provide said dependencies.

I don't know what industry you work in, who the regulatory body that certifies your code is, or what their procedures are, but if they're not certifying the "random library repos" that are part of your code, I pray I never have to interact with your code.

alexvitkov

10 miesięcy temudiscuss

No, I did not suggest that, in fact in the very comment you're replying to I said:

  My point was not that running all that on one computer is a great idea...

Regardless, if you want to strawman my passing remark, I'm happy to defend it.

Let's even say my numbers are wildly wrong, and they're processing 100x more transactions than what I claimed (which was already an overestimate). Tell me why you can't process 1600 transactions per second on one computer, especially for a country the size of the UK, where you would expect a ~15ms ping when talking to a server on the other side of the country.

alexvitkov

10 miesięcy temudiscuss

> If I am providing (lets say) a library that provides some high level features for a car ADAS system on top of a CAN network with a proprietary library as driver and interface.

If you're writing an ADAS system, and you have a "dependency tree" that needs to be "resolved" by a package manager, you should be fired immediately.

Any software that has lives riding on it, if it has dependencies, must be certified against a specific version of them, that should 100% of the time, without exceptions, must be vendored with the software.

> It is a guarantee of pain and ABI madness for anybody having to deal with the integration of your blob later on.

The exact opposite. Vendoring is the ONLY way to prevent the ABI madness of "v1.3.1 of libfoo exports libfoo_a but not libfoo_b, and v1.3.2 exports libfoo_b but not libfoo_c, and in 1.3.2 libfoo_b takes in a pointer to a struct that has a different layout."

If you MUST have libfoo (which you don't), you link your version of libfoo into your blob and you never expose any libfoo symbols in your library's blob.

alexvitkov

10 miesięcy temudiscuss

If you're doing 10 million transactions per week (which is likely way more than what they're pulling) that's about 16 transactions processed per second. You can add inventory management, payroll management, you can run the company's email server, write all that in JavaScript, and you'll still have room to run a Minecraft server on the same laptop.

My point was not that running all that on one computer is a great idea, just that 40,000 servers for a CRUD application is way past what should be considered reasonable.

But even that's fine. I like computers, you can have 40,000 of them if you want, even if the only reason they exist is some guy's job security. However, you're insane if the guy keeping them running doesn't work for you.

alexvitkov

10 miesięcy temudiscuss

You're making your customer's life miserable by having dependencies. You're a library, your customer is using you to solve a specific problem. Write the code to solve that and be done with it.

In the game development sphere, there's plenty of giant middleware packages for audio playback, physics engines, renderers, and other problems that are 1000x more complex and more useful than any given npm package, and yet I somehow don't have to "manage a dependency tree" and "resolve peer dependency conflicts" when using them.

alexvitkov

10 miesięcy temudiscuss

Play stupid games, win stupid prizes.

If you need 40,000 servers to keep your business running (which you don't, your ~3-8 million weekly transactions can be processed on 1 computer, but whatever), hire people that will work on you, and whose paycheck depends on keeping those computers working, to keep those computers working.

Game theory arguments like "they wouldn't screw me over because other people won't want to do business with them" don't work when the other party is trying to maximize quarterly earnings, and their long-term thinking is in the order of ~2 years.

alexvitkov

10 miesięcy temudiscuss

> Every pixel and every function went through me. The AI translated what I asked for into code, but every decision was human.

You'll find that programmers are a lot less prickly when you use AI to generate code, than say artists are, when you use it to generate pictures. You don't have to defend yourself, it's OK to use it to make cool things that you couldn't otherwise.

You should be aware though that even though it may "feel like magic" when just getting started, there's an upper limit to the complexity of what you can build with AI-generated code - it's very low quality and will start falling apart once you stack a lot of it. For the same reason I wouldn't recommend using it as a learning resource, if you really want to get into programming.

alexvitkov

10 miesięcy temudiscuss

> how capabilities could be used to write simple scripts without sacrificing simplicity.

I proposed a solution for that in my original comment - you should be able to trivially bypass the capability system if you trust what you're running ($ yolo my_script.sh).

The existance of such a "yolo" command implies you're running in a shell with the "full capabilities" of your user, and that by default that shell launches child processes only a subset of those. "yolo" would then have to be a shell builtin, that overrides this behavior and launches the child process with the same caps as the shell itself.

alexvitkov

10 miesięcy temudiscuss

The idiotic statement is yours. If the "sometimes" is important to you, you can have it - you're not the first person on the internet to play word games.

But unless you can come up with a very detailed list of when it's acceptable "to lock people down and physically prevent them from harming themselves" and when it's not acceptable (it never is, it's a crazy statement), and I don't think you have such a list, your "sometimes" just means "whenever I, as the person writing the software judge", rendering it completely meaningless.

alexvitkov

10 miesięcy temudiscuss

No, not everything is a trade-off. Some things are just good and some are just bad.

A working permission system would be objectively good. By that I mean one where a program called "image-editor" can only access "~/.config/image-editor", and files that you "File > Open". And if you want to bypass that and give it full permissions, it can be as simple as `$ yolo image-editor` or `# echo /usr/bin/image-editor >> /etc/yololist`.

A permission system that protects /usr/bin and /root, while /home/alex, where all my stuff is is a free-for-all, is bad. I know about chroot and Linux namespaces, and SELinux, and QEMU. None of these are an acceptable way to to day-to-day computing, if you actually want to get work done.

alexvitkov

11 miesięcy temudiscuss

Please read again the sentence you just typed.

> We have to lock people down and physically prevent them from harming themselves.

You can apply this argument to literally anything, and taken to its logical conclusion, this is exactly what will happen.

alexvitkov

11 miesięcy temudiscuss

"Don't use the phone."

Let me just give up on banking and the proprietary 2FA app that my job requires. Guess we're going homeless to protest Google, boys.

alexvitkov

11 miesięcy temudiscuss

It's not illegal to not release your software on a platform. But the mobile market is so top-heavy on both the apps and the games side, that without a few key developers - Meta, ByteDance, Tencent, etc your union is dead in the water - and the top 1% of developers would very much like to more friction for new developers, not less.

alexvitkov

11 miesięcy temudiscuss

Should I also change it on my mother's computer who doesn't speak English? We can also start distributing .bat files that change the system language along with our spreadsheets, for anyone who wants to open them. Maybe automate it with VBS, so it changes automatically when you open the spreadsheet. That's the solution.

alexvitkov

2 lata temudiscuss

That's fair, my comment did understate their relation quite a lot. They are very closely linked, to the point stuff has been added to the WebGPU spec pretty-much because "eh, it's already in wgpu".

But the "knowledge is transferable to WebGPU" is key. Even when you're compiling your wgpu code to WASM, you're not using WebGPU directly - for every API call, you're going through generated bindings on the Rust side and then generated bindings on the JS side where the actual call is made. The JS wrappers aren't trivial either - Rust structs need to be converted to the nested JS objects required by WebGPU spec, numeric enums need to be converted strings, etc.

Considering that WebGPU is supposed to be the low-level graphics API for the Web, DX12/VK/Metal equivalent, all this is at least worth a mention, and "wgpu == WebGPU" brushes over a all that, to the point where we're now casually throwing statements like "[WebGPU] is guaranteed to run anywhere, including the browser".

alexvitkov

2 lata temudiscuss

Vulkan, Direct3D, Metal and OpenGL are graphics APIs - the implementation comes with your GPU driver, and they're as close as you can reasonably get to writing code "directly for the GPU". When you call a Vulkan function you're directly calling driver code.

wgpu is a regular library that uses the native APIs above and abstracts them from you. I don't like calling it a graphics API because it implies it's the same as the vendor-provided APIs - it's a completely different beast.

WebGPU and WebGL are Web standards that the browser implements, and you program them via JS. Similarly to wgpu, they're implemented on top of the native graphics APIs.

The relationship between wgpu and WebGPU is that they're basically made by the same people, and in Firefox WebGPU is implemented on top of wgpu.

But saying "WebGPU runs everywhere" is plain wrong - it's a browser-exclusive API, and on top of that, at the point of writing this it doesn't even run on all browsers (71% support according to https://caniuse.com/webgpu)

alexvitkov

2 lata temudiscuss

wgpu is not WebGPU. One is a Web specification, the other is a Rust library.

wgpu is also not a graphics API, it's a library that abstracts the underlying graphics API.

comments