[-] [email protected] 3 points 1 day ago

I know. Then they process those user agent strings to decide what OS it is. The question is why are they treating OSX and macOS as different OSes when they are the same? It was literally just a rebrand.

[-] [email protected] 1 points 1 day ago

You shouldn’t be pulling an external project as a submodule, that’s just coupling yourself way way too tightly to external code.

You're no more tightly coupled than if you zip that repo up, and put it on an internal server. It's the exact same code you've just changed the distribution method.

And my whole point is that wouldn't be necessary if Git had a version of submodules that worked properly!

You guys seriously lack imagination.

[-] [email protected] 5 points 1 day ago

Why do they even have two lines for OS X and macOS? It's the same thing.

[-] [email protected] 3 points 1 day ago

Misguided investment IMO. Smart glasses hardware is still at least a decade from being something that normal people would want.

[-] [email protected] 1 points 1 day ago

Not my experience. More like 50% coding/debugging, 25% meetings, 25% admin/helping people/procrastinating.

[-] [email protected] 2 points 2 days ago

Yes I'm aware where Git came from.

Large files don’t work with git, as it always stores the whole history on your drive.

Not any more. That's only the default. Git supports sparse checkouts and blobless checkouts both of which only get a subset of a repo. And actually it has supported --depth for as long as I remember.

[-] [email protected] 4 points 2 days ago* (last edited 1 day ago)

Libraries are not always a suitable solution. You just haven't worked on the same projects I have and you can't imagine all the things submodules are used for.

On top of that, I can't force all third party projects to turn their repos into nice easily installable packages. Especially if they're using a language that doesn't have a package manager.

[-] [email protected] 1 points 2 days ago

So what? You can manually merge them. File locking is also a common solution (LFS supports that).

The level of "you're holding it wrong" here is insane.

[-] [email protected] 1 points 2 days ago

That can work in some cases, but it's usually not that great for first party projects where you want to be able to see and edit the code, and most package managers are OS or language specific so they don't work well with multi-language project or projects using a language that doesn't have a good package manager (SystemVerilog for example).

[-] [email protected] 19 points 2 days ago

Well, git is for source control, not binary artefacts

Only because it is bad at binary artefacts. There's no fundamental reason you shouldn't be able to put them in version control.

It's not much of an argument to say "VCSes shouldn't be able to store binaries because they aren't good at it".

What are your requirements? What do you need this for?

Typically there's a third or first party project that I want to use in my project. Sometimes I want to be able to modify it too (soft fork).

And why do you think everyone else needs the same?

Because I've worked in at least 3 companies who want to do this. Nobody had a good solution. I've talked to colleagues that also worked in other companies that wanted this. Often they come up with their own hacky solutions (git subtree, git subrepo, Google's repo, etc. etc. - there are at least half a dozen of these tools).

It’s quite possible you are doing it wrong.

No offence, but your instinctive defence of Git and your instant leap to "you're holding it wrong" are a pretty dead giveaway that you haven't stopped to think about how it could be better.

[-] [email protected] 22 points 2 days ago

Tbh these aren't things that are big issues with Git. The biggest issues I have are:

  • Storing large files. LFS is a shitty hack that barely works.
  • Integrating other repos. Git submodules are a buggy hack, and Git subtree is.. better... but still a hack that adds its own flaws.

Fix those and it will take over Git in a very short time. Otherwise it's just going to hang around as a slightly nicer but niche alternative.

[-] [email protected] 21 points 4 days ago

Full of WTFs.

My default development environment on Windows is the Linux-like MSYS2 environment

I think this sets the tone nicely lol.

it’s clear at this point already that Zig is a weakly-typed language

Uhm... pretty sure it isn't.

You can only use the zig command, which requires a special build file written in Zig, so you have to compile Zig to compile Zig, instead of using Make, CMake, Ninja, meson, etc. as is typical.

Yeah who wants to just type zig build and have it work? Much better to deal with shitty Makefiles 🤦🏻‍♂️

Ignoring the obvious memory safety red herring,

Uhhh

we can worryingly tell that it is also a weakly-typed language by the use of type inference

Ok this guy can be safely ignored.

the fact that the unsafe keyword is required to cooperate with C interfaces gives even great cause for concern

?

Rather than dealing with this ‘cargo’ remote repository utility and reliving traumatic memories of remote artefact repositories with NodeJS, Java, etc., we’ll just copy the .rs files of the wrapper directly into the source folder of the project. It’s generally preferred to have dependencies in the source tree for security reasons unless you have some level of guarantee that the remote source will be available and always trustworthy.

Lol ok... Ignore the official tool that works extremely well (and has official support for vendoring) and just copy files around and then is surprised that it doesn't work.

Although you can use the rustc compiler directly, it provides an extremely limited interface compared to e.g. Clang and GCC

That is a good thing.

You get similar struggles with just getting the basic thing off the ground

Uhm yeah if you ignore the tutorials and don't use the provided tools. It's literally cargo init; cargo run.

What an idiot.

25
submitted 3 months ago* (last edited 3 months ago) by [email protected] to c/[email protected]

Edit: rootless in this context means the remote windows appear like local windows; not in a big "desktop" window. It's nothing to do with the root account. Sorry, I didn't come up with that confusing term. If anyone can think of a better term let's use that!

This should be a simple task. I ssh to a remote server. I run a GUI command. It appears on my screen (and isn't laggy as hell).

Yet I've never found a solution that really works well in Linux. Here are some that I've tried over the years:

  • Remote X: this is just unusably slow, except maybe over a local network.
  • VNC: almost as slow as remote X and not rootless.
  • NX: IIRC this did perform well but I remember it being a pain to set up and it's proprietary.
  • Waypipe: I haven't actually tried this but based on the description it has the right UX. Unfortunately it only works with Wayland native apps and I'm not sure about the performance. Since it's just forwarding Wayland messages, similar to X forwarding, and not e.g. using a video codec I assume it will have similar performance issues (though maybe not as bad?).

I recently discovered wprs which sounds interesting but I haven't tried it.

Does anyone know if there is a good solution to this decades-old apparently unsolved problem?

I literally just want to ssh <server> xeyes and have xeyes (or whatever) appear on my screen, rootless, without lag, without complicated setup. Is that too much to ask?

17
submitted 9 months ago by [email protected] to c/[email protected]

Does anyone know of a website that will show you a graph of open/closed issues and PRs for a GitHub repo? This seems like such an obvious basic feature but GitHub only has a useless "insights" page which doesn't really show you anything.

10
Dart Macros (youtu.be)
submitted 1 year ago by [email protected] to c/[email protected]

Very impressive IDE integration for Dart macros. Something to aspire to.

view more: next ›

FizzyOrange

0 post score
0 comment score
joined 2 years ago