electroly

I once set up a Windows 11 VM. Everything was great. The first time it installed a feature update, it hit this BitLocker key input prompt on the reboot. Ugh. I was able to get the key but as soon as I was back into Windows, I disabled BitLocker on that VM and every other Windows machine I use. The risk of my machine being stolen and them finding some unencrypted private data is far easier to accept than the risk of me being suddenly and completely locked out of my computer, and I care more about the latter. Security isn't just about keeping bad guys out--it's also about making sure you can get in when you need it. Otherwise the only security you need is storing your data in /dev/null.

Thanks for that info--I think you're right and I'm wrong. I didn't see the group memberships before but now I see that the replier is far more involved in SUMO. I had only seen that they were both locale leaders and that the replier was a staff member from the tag on the post.

"SUMO" = SUpport.MOzilla.org. It's the name for the entire Mozilla support organization; everybody involved in the linked discussion is in this organization. It doesn't seem like this person is related to the bot. They are a "Locale Leader" for Indonesia, which is the same position this poster is resigning from (but for Japan). They seem to be peers.

"the typographic stylings ... are how he writes" is what I said, isn't it? :) Well said.

The beginning of the article talks about not learning APL--specifically mentions that he's not here to talk about APL--and proceeds into a wide-eyed dissection of the C without mentioning APL syntax again. It also doesn't, literally, say that the C is like APL; it says Arthur is an APL guy who writes weird C code. Another comment disagrees that this is APL style at all--which is it?? I think you could have given me more credit than this. I read the article and participated as best I could. I'm always happy to bump APL related articles so they get more visibility.

The way to understand Arthur Whitney's C code is to first learn APL (or, more appropriately, one of his languages in the family). If you skip that part, it'll just look like a weirdo C convention, when really he's trying to write C as if it were APL. The most obvious of the typographic stylings--the lack of spaces, single-character names, and functions on a single line--are how he writes APL too. This is perhaps like being a Pascal programmer coming to C and indignantly starting with "#define begin {" and so forth, except that atw is not a mere mortal like us.

There is some discussion about this from smarter people than me over here (same thread): https://news.ycombinator.com/item?id=45769149

> Counterintuitively Julia recommends the use of immutable data types for performance reasons...

Those folks are likely more able to respond to your counterclaim than me.

Several times, I had MTurk workers transcribe a yearly printed pricing catalog that was a boon to our small business. Inconsistently-structured tabular data intermixed with pictures that OCR of the day did a terrible job with.

Later, we needed to choose the best-looking product picture from a series of possible pictures (collected online) for every SKU, for use in our website's inventory browser. MTurk to the rescue--their human taste was perfect, and it was effortless on my part.

Neither of these were earthshattering from a tech perspective, and I'm sure these days AI could do it, but back then MTurk was the perfect solution. Humans make both random and consistent errors and it was kinda fun to learn how to deal with both kinds of error. I learned lots of little tricks to lower the error rate. As a rule, I always paid out erroneous submissions (you can choose to reject them but it's easier to just pay for all submissions) and just worked to improve my prompts. I never had anyone maliciously or intentionally try to submit incomplete or wrong work, but lots of "junk" happens with the best of intentions.

Oh, I meant that I suspect it's a bad idea. I've got a gut feeling that I can't put my finger on. I implemented it anyway because my language's design "pointed" in that direction based on prior decisions I had made (re: not having any reference semantics), but I can't shake the feeling that I've created something internally consistent but confusing to people trying to learn it. Or that it will hit a wall at some point and I'll suddenly realize why this is not done. I'll have to think about it some more. Thanks for the discussion!

That's always the case with immutable data structures; this assignment syntax didn't create that problem. If you used lenses to write 2 into "a", and you expected to get back a new "obj", you would still need to produce all those new objects and arrays. That's just immutable data structure stuff. I'm only asking about the assignment syntax here.

My language doesn't have any other kind; it's not immutable by default, it's immutable only. There are no mutable types or reference semantics, so there's no other kind of type that I need to differentiate. That's my question--why haven't other languages taken this approach? Many newer languages today are full-throated defenses of immutable data structures--why do they still make the mutable structures the easiest, syntactically, to change? Why not the other way around? Julia is fastest with immutable structures--why provide a built-in syntax for complex assignment to mutable types, but then relegate lenses to a library that only FP aficionados will use? We don't want add() and subtract() when we have + and -; why should we live with set() when we have =?

I must be missing it because it worked out pretty nicely in my toy language. Complex assignments are written in exactly the way that people expect them to be. That's why I think it must be about taste or practical consideration--obviously it's possible to write a language like this. But experienced designers don't, presumably because it's a bad idea, and I don't understand what the badness is. Since my language is a toy, I likely haven't hit the practical considerations.

Lenses, to me, feel at home in Haskell where the entire language is a game to see how much theory you can implement in the "userspace" of a tight, maximally-orthogonal FP language. But this is Julia, a monstrously large, imperative, Algol-family language with every possible language feature built-in, intended to be a practical language for analysis by people who aren't programming language experts. Julia's compiler already has knowledge of immutable types which it uses for optimization. Seems like they could do better than lenses if they weren't forced to implement it as a library in the language itself.

The other replies covered the answer about immutability well, but I have the further question: why isn't this built into languages as syntax sugar, so that OP's suggested line would work with immutable structures?

As a dilettante at programming language design, I have my own toy language. It uses exclusively immutable data structures (C++ "immer"). I present it to the programmer as simple value semantics. `obj.foo[5].bar.a = 2` works and sets `obj` to a new structure where the path through `foo`, `bar`, to `a` has all been rewritten. Since I put it in as a language feature, users don't have to learn about lenses. Why isn't this technique more common in programming language design? Is it so offensive that the syntax `obj.a = 2` ends up rebinding `obj` itself? The rule in my language is that assignment rebinds the leftmost "base" of a chain of `.` field and `[]` array index accesses on the LHS. I'm ignorant of the theory or practical consideration that might lead a competent designer not to implement it this way.

Ah, of course! Thank you for this correction.

EC2 instances have dedicated throughput to EBS via Nitro that you lose out on when you run your own EBS equivalent over the regular network. You only get 5Gbps maximum between two EC2 instances in the same AZ that aren't in the same placement group[1], and you're limited by the instance type's general networking throughput. Dedicated throughput to EBS from a typical EC2 instance is multiple times this figure. It's an interesting tradeoff--I assume they must be IOPS-heavy and the throughput is not a concern.

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-inst...

An empty parking lot is effectively the gold standard for opposite-of-claustrophobia as the article seems to intend the term. It's the least claustrophobic space possible on the surface of the Earth. Even an open meadow is less open than an empty paved parking lot because it has small bushes and shrubs everywhere. This matches my intuition as a mild sufferer--I actually try to picture a brightly lit gas station parking lot if I'm feeling claustrophobic.

AWS documents it as "After modifying a volume, you must wait at least six hours and ensure that the volume is in the in-use or available state before you can modify the same volume" but community posts suggest you can get up to 8 resizes in the six hour window.

I put our company onto a hybrid AWS-colocation setup to attempt to get the best of both worlds. We have cheap fiddly/bursty things and expensive stable things and nothing in between. Obviously, put the fiddly/bursty things in AWS and put the stable things in colocation. Direct Connect keeps latency and egress costs down; we are 1 millisecond away from us-east-1 and for egress we pay 2¢/GB instead of the regular 9¢/GB. The database is on the colo side so database-to-AWS reads are all free ingress instead of egress, and database-to-server traffic on the colo side doesn't transit to AWS at all. The savings on the HA pair of SQL Server instances is shocking and pays for the entire colo setup, and then some. I'm surprised hybrids are not more common. We are able to manage it with our existing (small) staff, and in absolute terms we don't spend much time on it--that was the point of putting the fiddly stuff in AWS.

The biggest downside I see? We had to sign a 3 year contract with the colocation facility up front, and any time we want to change something they want a new commitment. On AWS you don't commit to spending until after you've got it working, and even then it's your choice.

Sure, this seems to be a restatement of my post, which started with "While true...", rather than a disagreement. I was pointing out which one of the "many acceptable opposing answers" Apple had chosen. They can't use that die area for performance because they're still using it even after this phase-out. (I'm not the person who wrote the original post.)

While true, we're not talking about the chips losing TSO; Apple plans to keep Rosetta 2 for games and it has to remain fast because, well, it's video games. It also seems like they plan to keep their container tool[1]. This means they can't get rid of TSO at the silicon level and I have not heard this discussed as a possibility. We're only discussing the loss of the software support here. The answer to "How much die area does it use that could be used for performance?" is zero--they have chosen to do a partial phase-out that doesn't permit them to save the die space. They'd need to kill all remaining Rosetta 2 usage in order to cull the die space, and they seem to be going out of their way not to do this.

[1] https://github.com/apple/container -- uses Rosetta translation for x64 images.

OXO sells borosilicate glass bakeware if you're looking for an alternative in America. The original PYREX is available for Europeans.

For non-graphical apps, you can link statically against musl to produce a binary that only depends on the Linux kernel version and not the version or type of libc on the system. You may take a performance hit as musl isn't optimized for speed, and a size hit for shipping your own libc, and a feature hit because musl is designed to be minimal, but for many command line tools all of these downsides are acceptable.

I believe it depends on the era and system, but there were various APL codepages (i.e. definitions for the upper 128 characters) for both EBCDIC and ASCII.

https://en.wikipedia.org/wiki/Digital_encoding_of_APL_symbol...

In the very earliest IBM Selectric teletype-based systems, some APL symbols were constructed by entering one character, hitting backspace, and overstriking a second character. For instance, ⍋ is | overstruck on ∆. It's why a lot of APL symbols look like that.

https://aplwiki.com/wiki/Overstrike

Not exactly the same, but on Windows if you use entirely Win32 calls you can avoid linking any C runtime library. Win32 is below the C standard library on Windows and the C runtime is optional.

It doesn't mean that here. Epdsv6 is 1 core = 1 vCPU.

You're not confused--AWS either gets custom chips without it, or they disable the SMT. I'm not sure which. Here's where AWS talks about it: https://aws.amazon.com/ec2/instance-types/m7a/

> One of the major differences between M7a instances and the previous generations of instances, such as M6a instances, is their vCPU to physical processor core mapping. Every vCPU on a M7a instance is a physical CPU core. This means there is no Simultaneous Multi-Threading (SMT). By contrast, every vCPU on prior generations such as M6a instances is a thread of a CPU core.

My wild guess is they're disabling it. For Intel instance families they loudly praise their custom Intel processors, but this page does not contain the word "custom" anywhere.

I'm confused about where the prohibition is. N991SS is an example of an FAA aircraft registration number for a balloon; I looked it up myself on the FAA N-number inquiry site to confirm. Your link does not talk about balloons at all. Where does the FAA prohibit weather balloons here? It sounds like it's just physically not possible to carry a transponder or reflector on a small weather balloon? But that's different than what the earlier posts were suggesting. It seems like it's physics preventing ADS-B on small balloons, not the FAA. If you did manage to get ADS-B on your balloon somehow, could you not register the balloon like the owners of N991SS did?

That's always the case with AWS: reducing costs takes legwork, and by the same token, you can avoid legwork by accepting a higher bill.

m7a doesn't use HyperThreading; 1 vCPU is a full dedicated core.

To compare to Heroku's standard dynos (which are shared hosting) you want the t3a family which is also shared, and much cheaper.

Assuming you're playing the "only pay for a business support plan when you actually need to file a ticket" game like me, with a very slight amount of effort this works in your favor instead of being a downside. Put your expensive-but-reliable stuff (e.g. large 24/7 EC2 instances, your S3 buckets) in one account and your cheap-but-fiddly stuff (e.g. your EKS cluster) in another account. When you need support on the fiddly stuff you're only paying a percent of that account.

At work we did not follow this advice, so we have a single account and we're vulnerable to an unnecessarily high support bill if we happen to need to file a ticket in an expensive month. We could have avoided this with account segmentation; our expensive stuff tends not to be the stuff we need support on.

In R, this is: x <- solve(A, b)