electroly

They don't have to be. I have a traditional non-sandboxed app with an MSIX installer. It's less flexible than MSI but it doesn't mandate a sandbox for the installed application.

They recently acknowledged and fixed this issue. I can personally confirm it hasn't happened to me since the update.

https://www.pcmag.com/news/microsoft-fixes-update-and-shut-d...

FWIW, the top comments at the time of my comment (one hour after yours, two hours after the article was posted) are all complimentary. You commented one hour after the article was posted; it's worth waiting a bit for the comment voting to shake out.

I can't imagine a situation where that sort of response isn't rude. It's polite to assume people have thought about their opinions, and to address the points rather than the person. If they didn't think it through, then you can counter their points.

In any event, I don't think Walter needed any help here. He is an HN veteran and always willing to discuss the points. Every programming language designer loves an opportunity to discuss their language with interested people! There's almost never a truly right answer in language design, just various tradeoffs.

They eventually upgraded the BeBox to the 603e, I wonder if the same L2 workaround was used on those models.

I think you are misunderstanding what C# does here, and what the original poster was suggesting. Maybe we did a poor job of describing it; I assumed people knew C#. The key words in OP's post were "before first use." It sounds like you interpreted this to mean "every variable declaration must immediately assign a value" but that's not how it works. I'll explain C#'s semantics.

An assignment is required at some point before the first read, not in the declaration. It tracks assignments and usages, and it flags a compiler error if you read a variable before assigning to it for the first time. A variable that hasn't been assigned cannot be read.

It means you can do "int a;" and then later in the function do "a = 5;" and the compiler guarantees that you never read the variable before the assignment in any path through the function. You cannot do "int a;" and then read from it; that's a compile-time error.

It does not mean you have to assign something in the declaration. We never need "vacuous" initializations, and this solution works on all types. Indeed, we avoid vacuous initializations so that the compiler will catch use-before-assign bugs at compile time. The situation you described doesn't happen in C#. Our C# variables become readable on their first assignment, not their declaration; the declaration merely sets the scope. There's no need for a state where it's initialized to an invalid value before receiving the first intended assignment, because in C# the variable is completely inaccessible during that time.

C# requires explicit assignment. If an appeal to authority sways you (it shouldn't), you can substitute Anders Hejlsberg instead of this random OP. How long do you suppose Anders Hejlsberg thought about this?

But I contend it's more useful (and interesting) to think about the idea with your own mind instead of tallying up the perceived authority of its supporters and relying on trust. It was also somewhat rude to suggest that the OP had not given their idea much thought. This is a forum for discussion, isn't it?

They're right. This is over the top. Your initial post in this thread was sensible (telling the users of Pgbackrest that they should have supported it if they didn't want this to happen, and saying nothing about what emotions are valid to have), but you took it much further here. People should financially support the OSS projects they use, and the lack of such support is why this project is no longer maintained, but claiming people aren't allowed to feel anything about it is just playing a game that isn't helping the cause. We all know this problem, and being sad while having not supported the project isn't a statement that we disagree that the problem exists. It's a big stretch to assume that it is.

I've never heard of this project before and I still think it's a bummer that a tool people liked and that the maintainer cared about was unable to find backing. I was never going to support it; I just heard of it for the first time today and I don't use it! I'm still sad. We're not robots here. We're fellow developers, and we know it's tough out there.

I used it for https://tmbasic.com to build an IDE in the style of Turbo Pascal for my toy language. Originally, I was going to implement the TV wrapper framework and UI builder in this project instead, so you could write TUIs in TMBASIC, but that ultimately felt like a waste for a toy language. With .NET someone might actually use it :P

I've sent you an email with the Turbo Vision books in Markdown, if you didn't receive it, hit me up via the email in my profile.

Definitely. Reach out to me or magiblot if you ever need any help. I love this stuff, and magiblot is extremely responsive. They have helped me many times and even made changes to tvision to support my use cases.

As a stretch goal, you might try to integrate https://github.com/magiblot/turbo too. This is a Scintilla-based text editor control implemented in tvision. We worked together to make it embeddable in other programs (because I wanted it in mine). Example usage: https://github.com/tmbasic/tmbasic/blob/master/src/tmbasic/C...

Also, I assume you know about the Turbo Vision Pascal and C++ books. They're really helpful. I transcribed both books to Markdown for easy searching if you want it.

I've done some work with this tvision port as well. Every time I use a new TUI framework, I'm disappointed. Invariably, Turbo Vision is better.

I'm actually working on my own .NET wrapper, too. I don't think I'm as far as you, though. I'm mimicking the Windows Forms API as closely as possible and I want to have a drag-and-drop TUI designer.

Some examples of my wrapper: https://github.com/brianluft/terminalforms/tree/main/src/Ter...

I did most of the hard integration work on the C++ side: https://github.com/brianluft/terminalforms/tree/main/src/tfc... -- exporting simple C functions that I can call with P/Invoke so that the C# side is mainly about organizing into classes. It took a couple tries to find a design that didn't fall apart when I got into more complicated stuff. Initially I went too hard into "everything that you can do in C++ should be possible in C#"--this was maddeningly complex. I was using placement new to stick the C++ objects into C# buffers, you could effectively subclass the C++ classes from the C# side, it was getting way too involved. I switched to a much more direct and less flexible approach. I decided the flexibility should be on the C# side.

I'm curious how your P/Invoke system works.

You've just constructed your own crappy in-memory zip file, here. If you have to build your own custom index, you're no longer using the standard tools. If you find yourself building indices of tar files, and you control the creation, give yourself a break and use a zip file instead. It has the index built in. Compression is not required when packing files into a zip, if you don't want it.

> I'd argue the k8s APIs and interfaces are better than trying to do this on AWS

I think Amazon ECS is within striking distance, at least. It does less than K8S, but if it fits your needs, I find it an easier deployment target than K8S. There's just a lot less going on.

> A lot of this is issues Microsoft could fix if they were sufficiently motivated...

They did fix it, in a sense, with WSL1 picoprocesses. Faster and more compatible than Cygwin. Real fork and exec on the Windows NT kernel. Sadly, WSL2 is even faster and more compatible while being much less interesting. WSL1 was pretty neat, at least, and is still available.

In any event, this diversion doesn't change my analysis of Cygwin. Cygwin still sucks regardless of whose fault it is. I intentionally left this stuff out of my post because I thought it was obvious that Cygwin is working around Windows limitations to hack in POSIX semantics; it's the whole point of the project. None of us can change Windows or Cygwin and they're both ossified from age and lack of attention. We have to live with the options we've actually got.

If you need a Windows build of a Linux tool in 2026 and can't use WSL, try just building it natively (UCRT64, CLANG64, MSVC, your choice) without a compatibility layer. Lots of tools from the Linux ecosystem actually have Windows source compatibility today. Things were different in the 90s when Cygwin was created.

My personal experience with our legal department on naming is that if your product name includes someone else's trademark, you have to say "Our Thing for Their Thing", exactly like that. I was involved in a product that did this, and we came up with some better names, but legal said no, it must be named with "for Their Thing" at the end. Those were the magic words so we don't get sued, and indeed, we weren't sued. Our legal was non-technical and never heard of WSL; they came to this conclusion independently.

The name we shipped was even worse than Windows Subsystem for Linux, honestly. At least Microsoft spent some time on it.

I can't answer for NVIDIA but AWS has its own training and inference chips, and word on the street is the inference chips are too weak, so some companies are running inference on the training chips.

Technically correct by some estimation, perhaps, but Cygwin is a crazy approach, was slow (contrary to the implication of the "low cruft" claim), was not as compatible as these other approaches, required recompilation, and was widely disliked at most points in its life. There's a lot of crazy voodoo stuff happening in cygwin1.dll to make this work; it totally qualifies as "hacking in some foreign Linux plumbing", it's just happening inside your process. Just picture how fork() is implemented inside cygwin1.dll without any system support.

Cygwin doesn't work at all in Windows AppContainer package isolation; too many voodoo hacks. MSYS2 uses it to this day, and as a result you can't run any MSYS2 binaries in an AppContainer. Had to take a completely different route for Claude Code sandboxing because of this: Claude Code wants Git for Windows, and Git for Windows distributes MSYS2-built binaries of bash.exe and friends. Truly native Windows builds don't do all the unusual compatibility hacks that cygwin1.dll requires; I found non-MSYS2-built binaries of the same programs all ran fine in AppContainer.

You mean that if you were Anthropic, you'd build the data centers on every continent? Can you explain your reasoning?

We're talking about billions of dollars of extra capex if you take the "let's build them everywhere" side of the bet instead of "let's build them in the cheapest possible place" side. It seems to me that you'd have to be really sure that you need the data center to be somewhere uneconomical. I think if you did build them in the cheap place, it's a safe bet that you'll always have at least enough latency-insensitive workloads to fill it up. I doubt that we would transition entirely to latency-sensitive workloads in the future, and that's what would have to happen for my side of the bet to go wrong. The other side goes wrong if we don't see a dramatic uptick in latency-sensitive inference workloads. As another comment pointed out, voice agents are the one genuinely latency-sensitive cloud inference workload we have right now; they do need low latency for it. Such workloads exist, but it's a slim percentage so far.

I believe I'm taking the safe bet that lets Anthropic make hay while the sun shines without risking a major misstep. Nothing stops them from using their own data centers for cheap slow "base load" while still using cloud partners for less common specialized needs. I just can't see why they would build the international data centers to reduce cloud partner costs on latency-sensitive workloads before those workloads actually show up in significant numbers.

tbh, that's a good point about the voice agents that I hadn't considered. I guess there are some latency-sensitive inference workloads. Thanks for pointing that out.

They want it, sure. Customers want everything if it's free, but this is about what they value with their money. In this thought experiment, you're Anthropic, not the customer. You're making a choice that's best for Anthropic. Will Anthropic lose customers because the latency is higher? No way. Customers want low cost and lots of usage more than they want low latency. In a cutthroat race to the bottom, there's no room to "give away" massively expensive freebies like a data center near every population center when the customer doesn't value those extras with actual money. It's the same reason we all tolerate the relatively slow batched token generation rate--the batching dramatically lowers the cost, and we need low cost inference more than we want fast generation. If the cost goes up we'll actually leave, for real.

After the initial announcement of "fast mode" in Claude Code, did you ever hear about anyone using it for real? I didn't. Vanishingly few people are willing to pay extra for faster inference.

Remember that the time-to-first-token is dominated by the time to process the prompt. It's orders of magnitude more latency than the network route is adding. An extra 200 milliseconds of network delay on a 5-10 second time-to-first-token is not even noticeable; it's within the normal TTFT jitter. It would be foolish to spend billions of dollars to drop data centers around the world to reduce the 200 milliseconds when it's not going to reduce the 5-10 seconds. Skip the exotic locales and put your data centers in Cheap Power Tax Haven County, USA. Perhaps run the numbers and see if Free Cooling City, Sweden is cheaper.

For AI inference you don't need to geographically distribute your data centers. Latency, throughput, and routes don't matter here. When it's 10 seconds for the first token and then a 1KB/sec streamed response, whatever is fine. You can serve Australia from the US and it'll barely matter. You can find a spot far outside populated areas with cheap power, available water, and friendly leadership, then put all of your data centers there. If you're worried about major disasters, you can pick a second city. You definitely don't need a data center in every continent.

You're not wrong about the rest but no AI company would ever build a data center in every continent for this, even if they were prepared to build data centers. AI inference isn't like general purpose hosting.

The author of Fil-C, who is also the author of this language, uses "Yolo-C/C++" to mean regular C/C++ without Fil-C.

I'm curious, do you know which virtual machines (i.e. what emulator and what OS) you would want? Does the software exist and it's just a matter of the time to set it up? Or is it harder to get ahold of all the necessary old software (even if you have the emulator)?

Maybe in the modern age someone could make a "polarhome in a box" that offers a similar gamut of systems, but via preconfigured emulators that you can simply download and run.

When some component in OP's dedicated server fails, they will find out what that extra DO money was going toward. The DO droplet will live migrate to a healthy server. OP gets to take an extended outage while they file a Hetzner service ticket and wait for a human to perform the hardware replacement. Do some online research and see how long this often takes. I don't believe this Hetzner dedicated server model even has redundant PSUs.

Anyone who thinks DO and Hetzner dedicated servers are fungible products is making a mistake. These aren't the same service at all. There are savings to be had but this isn't a direct "unplug DO, plug in Hetzner" situation.

I've done this for real, in commercial code that shipped. No trust needed; I have personal experience. For typical minor MessageBox additions, this can be easier than rebuilding the whole dialog yourself. Sometimes, we just wanted to add a "Don't ask again" checkbox which didn't require touching the existing child windows at all. I also used this technique to simply change the labels on the buttons to custom text. I had a MessageBox wrapper that accepted a list of button strings instead of a predefined constant. We've all built various custom message boxes, of course, but not every situation required that level of effort.

These days you can just use a TaskDialog, of course, and it's way more flexible than MessageBox. But it's fun to remember the old techniques.

I like it. Genuinely, I think APL only reuses glyphs for dramatically different monadic vs. dyadic behavior because there were limited positions available on a Selectric type ball. Many glyphs are reused as-is for multiple meanings, and they had to build some glyphs by overstriking a second glyph on top of an existing one. None of this is a concern these days.

That said, some of the reuses do make sense. ⍴ as monadic shape and dyadic reshape makes perfect sense. In FIXAPL, shape is △ and reshape is ⍴; the symbols have nothing to do with each other. I think that particular separation is a loss rather than a gain.

My memory from the old days is you can use Win32 hooks to modify the MessageBox. HCBT_CREATEWND gets you the HWND of the MessageBox, and you can subclass it (in the Win32 sense) to insert your own WndProc. Then you're off to the races--it's your dialog now.

You're right. I've edited my post not to accuse the author of lying.

The author wrote "No rules beyond basic ethics and law" which suggests to me that there were instructions in a prompt and the title may be misleading.

I had forgotten that you had to individually request AWS services early on. I checked my email history from 2007 and it's true, I was initially only granted access to "Amazon E-Commerce Service"! I got a separate email confirming that I had signed up for S3. Funny that they hadn't yet figured out that the automatic "package deal" is one of their biggest selling points.

The next service I signed up for was "Alexa Web Information Service". Web search as a service, back when "Alexa" was the search company they had acquired, not a voice assistant. By mid-2007 I was (finally) accepted into the EC2 beta. The rest, as they say, is history.