Rsync is pretty closely tied to unixy concepts of permissions, paths, access times, etc. You can find some rsync based tools for Windows, but IMO, it's a square peg / round hole unless you're using it inside of WSL.
Kinda, sorta. Robocopy is a very good tool, but it cannot do incremental file updates. Already mentioned bvckup2 can do deltas, but it's not an rsync client.
Are you sure the others use Squirrel? After it’s maintainer decided to crash out and abandon multiple libraries including Squirrel, I was under the impression it was abandoned?
Squirrel is abandoned for years and still used anyway, often by people who don't realize it's abandoned. It's the default if you use the Electron toolchain, so that's why. It has serious design problems too, like it breaks Windows networks by bloating people's roaming home directories with dozens of independent copies of Chrome which then get backed up, copied around on login etc. Admins loathe it as the whole point of this design is to bypass their ability to manage their own deployments, although they still get the blame when things break, of course.
There's a better way, which I am shamelessly self-promoting in this thread (as it's 100% on topic) - my company makes a tool that can ship self-updating Electron apps and beyond being not abandoned, it's got a lot of really useful features, like being able to do the build and upload of signed updating packages (using the tech MS is pushing here) from Linux CI workers, without needing a Windows license.
It can also do forced updates on launch, which can be helpful for apps where the protocol between client and server changes regularly. And it plays well with corporate Windows deployments. People can install apps locally without needing administrator access but it goes into c:\Program Files
That’s awesome, but keep in mind that the AppData thing is likely a feature and not a bug.
Think about it another way: if they install in AppData, they can likely bypass IT depts and other business bureaucracies and get a foothold somewhere in an organization. It’s absolutely malicious, both in terms of tech and business practices, but it works.
That might have been true a long time ago, but nowadays Windows makes it easy to black/whitelist executables from the home directory with stuff like AppLocker. Meanwhile, the MSIX subsystem lets users install apps safely without needing admin access into c:\Program Files.
So, what Electron does might have been a neat growth hack once, but now it's as likely to hit roadblocks as not (at least on any modern Windows network with a switched-on IT department).
The worklet API gives the browser the ability to spawn as many threads for the task as it wants when it wants, without needing to communicate and wait on the page's code in the main javascript thread each time.
The last time I read any updates on this, everyone on both sides of the legal process were trying to single out scapegoat individual software engineers and rake them over the coals. Did something change?
I don't think software engineers were independently looking at emissions data and unilaterally decided to "fix" the emissions shortcomings in software. I think they were told by others to do that. It's good that Germany is going after the people who decided that fraud was the answer.
> It's good that Germany is going after the people who decided that fraud
When the VW scandal broke, the US indicted seven senior executives. None of these seven were extradited to the US to stand trial [1].
The VW scandal was made public in 2015 [2] and involved cheating since 2009. Sentencing only two executives to jail a decade after their wrong doing made international news does not send a strong message.
When the VW scandal broke, the US indicted seven senior executives [1]. Germany did not cooperate. None of these seven were extradited to the US to stand trial.
One more mid level engineer involved in the scandal made the mistake of taking a vacation to Florida. He was arrested in the airport awaiting his flight home to Germany [2]. He was sentenced to 84 months in prison but was let out after serving half of that sentence [3].
Germany does not extradite its nationals to the US at all. Not sure why would you expect this case to be so special that Germany would break its own laws.
You're stating this very confidently, but I don't think it's a blanket non-extradition policy. In the case of a potential death penalty, it's a clear no, but that's not the case here.
Article 16 (2) No German may be extradited to a foreign country. The law may provide otherwise for extraditions to a member state of the European Union or to an international court, provided that the rule of law is observed.
USA is not a member of European Union nor an international court.
I’m imagining a really, really, really rough ride for this. I don’t mean the compiler, tsc CLI, or VS support. I know the TypeScript team will have already competently done their side of the story.
I think that as usual, it’s going to be the hellscape ecosystem of Node that is going to be a complete pain here for devs just wanting to use TypeScript.
Somehow, the vast myriad of tools and their dependencies, find a way to make writing TS/JS worse while trying to make it better.
You’d expect a simple package change to be straightforward, but after ten years of dealing with web tooling ranging from before the webpack era to now, I am constantly amazed by the new ways these tools manage to fuck everything up.
I imagine for Deno the change to the new compiler will be seamless and not even noticeable.
It basically depends how deep the other tooling is sticking its claws into TS internals which won’t be accessible in the same way anymore.
I’ll bet the two most painless improvements will be:
- tsc just for type checking. (A lot of places run tsc just as a type checking step, and avoid type checking during the full build.)
- TS language server. By far the worst part of TS for large repos today — in my main monorepo, it consumes like 10GB of RAM and actions like “jump to definition” become so slow that it’s unusable.
Things that may be painful:
- Integration with 3rd party compilers like webpack which use TSC. Also unsure how tools like Rspack will need to consume tsc, given that they use a highly parallel rust architecture already.
- Integration with tools like Jest which need to transpile code before running TS.
- Integration with running Node directly — eg swchook or ts-node for bin scripts
> An annotation can be thought of as a comment, recommendation or a like on any piece of content. Ann allows you to store your annotations, send annotations to your followers and receive annotations from people that you follow.
It's worth remembering that Windows 1.x and 2.x predates the C89 standard. This also explains why WINAPI calling convention was inherited from Pascal instead of C. The C standard library was "just another competitor" at the time.
The WINAPI calling convention is a cross between C and Pascal - C-style order of arguments on the stack, but Pascal-style callee cleaning the stack before return.
The reason for its use in Windows is that it makes generated code slightly smaller and more efficient, at the cost of not supporting varags easily (which you don't need for most functions anyway). Back when you had 640 Kb of RAM, saving a few bytes here and there adds up quickly.
Windows didn't standardize on C. It was mostly assembly and some Pascal in the beginning with C and C++ later.
Microsoft have always viewed C as just another language, it's not privileged in the way UNIX privileges C. By implication, the C standard library was provided by your compiler and shipped with your app as a dependency on Windows, it wasn't provided by the operating system.
These days that's been changing, partly because lots of installers dumped the MSVC runtime into c:\windows\system and so whether it was a part of the OS or not became blurred and partly because Microsoft got more willing to privilege languages at the OS level. Even so, the Windows group retains a commitment to language independence that other operating systems just don't have. WinRT comes with lots of metadata for binding it into other languages, for example.
> Windows didn't standardize on C. It was mostly assembly and some Pascal in the beginning with C and C++ later.
No, it was never Pascal. It was always C from the beginning. You may have been confused by them using the Pascal calling convention because it was generally faster on the 16-bit CPUs of the time.
Apple was the one going with Pascal for the OS, originally the Object Pascal linage was started at Apple, in collaboration with Niklaus Wirth that gave feedback on the design.
Unlike Unix, Windows historically didn't have a standard C runtime at all. Stuff like MSVCRT.DLL etc came later (and are themselves implemented on top of Win32 API, not directly on top of syscalls as is typical in Unix land).
