colatkinson

Woah I hadn't. Looks super useful, thanks!

Yeah the cross-compilation thing is definitely a rough spot. I have one project that's able to work around it via extensive hacks with macros, but at some point I'll need to do it "the right way."

Honestly if the docs had a canonical example of e.g. using unix_cc_toolchain_config (example: [0]) + Bootlin to compile for aarch64, it'd probably go a long way to making things understandable. Because say what you will about the old CROSSTOOL approach, at least there was a nice tutorial for it.

[0] https://github.com/grailbio/bazel-toolchain/blob/f14a8a5de8f...

Is it proprietary? According to their blog, Pyston was open sourced with version 2.2 [0], and the LICENSE file in the repo [1] appears to be the same as upstream CPython.

Not a rhetorical question BTW. A pluggable JIT for Python could be a boon for some projects at my dayjob, but if it's proprietary that would put a bit of a damper on things.

[0]: https://blog.pyston.org/2021/05/05/pyston-v2-2-faster-and-op...

[1]: https://github.com/pyston/pyston/blob/pyston_main/LICENSE

Median household income in NYC for 2020 was $67k [0]. $100k (especially for a single earner, as is often the case in tech) is considered quite high, but not outrageously so if that makes sense? That's "1BR apartment in a nice but not too trendy neighborhood outside of Manhattan" money, so well on the upper side of middle class. I think people tend to overestimate how much money those outside of the tech bubble actually make.

[0] https://www.census.gov/quickfacts/fact/table/newyorkcitynewy...

What do you think would happen to an LGBT person in, say, Saudi Arabia? The answer is, "capital punishment, fines, public whipping, beatings, vigilante attacks, vigilante executions, torture, chemical castrations, imprisonment up to life and deportation." Those seem like they're well into the category of "real human violations."

This is also not a hypothetical situation -- something quite similar happened in Egypt a few years ago [1]. And that was using good old fashioned entrapment. The damage could have been far more significant with large-scale data analysis.

While I can't speak for OP: they likely feel comfortable posting about their gender/sexuality on here because they live in a place where that won't happen. And while HN is often less than progressive on LGBT issues, users here generally aren't calling for public executions. But not everyone lives in the US or Western Europe, and these people live under a genuine threat of death.

[0] https://en.wikipedia.org/wiki/LGBT_rights_in_Saudi_Arabia

[1] https://www.independent.co.uk/news/world/middle-east/egypt-l...

> Some of these are colloquial, but their existence also points to the fact that there are groups that weren't served exlusively with the gendered "guys".

Most of the replacements you cited are regional:

- Y'all is Southern/AAVE.

- Them is third-person, whereas "you guys" is second-person.

- "Yinz" is from Pittsburgh.

- I'm gonna throw in "youse," one of my faves, which is from New Jersey/Philly.

"Guys" is clearly gendered, whereas "you guys," I'd argue, generally isn't--especially in the Northeast US. I frequently hear cis women refer to groups of entirely cis women as "you guys."

This isn't meant as a view of what the ideal state of the English language is (bring back "thou!"), but these discussions frequently involve people talking past each other, and conflating "you guys" (second-person plural, arguably gendered) with "guys" (third-person plural, usually gendered). Effectively replacing "you guys" is a more challenging task, since there isn't a universally agreed-upon alternative, at least in the US.

I'll leave it to others to figure out what that alternative should be, though I will note that I, as a WASP from the Northeast, sound completely ridiculous saying "y'all."

Microsoft Teams is distributed through the Play Store. If iOS provided a similar API with a similar bug, the same thing could happen there. So clearly, blocking side-loading would have had no impact on this particular issue.

If you're worried about low-quality software being side-loaded onto the phone, you can just not side-load anything. That's probably how most Android users use their devices. But it's nice that the walled garden has a gate.

The "marketing fluff" is here [0]. From my understanding, the relatively novel things they're doing at the lowest levels are making it a microkernel, and using a capability-based security model [1].

The former decreases the Ring 0 attack surface, and the latter makes it challenging to cause a confused deputy problem -- you know, the ol' classic "whoops this daemon running as root accidentally allowed a browser tab to read /etc/shadow." Or the time honored problem of a single exploit in one process giving access to all files (and in some cases, all processes' memory and resources) controlled by a given user. Capabilities also make it relatively easy to sandbox userspace code, and to reason about what it has access to. Kinda like containers, but as a core concept rather than tacked on a few decades into development.

Now these concepts aren't new, but they haven't been deployed or supported at the scale Fuchsia may end up at. Which obviously makes it a pretty exciting project in terms of real-world impact. That said, I believe there's been some speculation that part of the motivation for Fuchsia is to avoid the mess that is out-of-tree drivers on Android. So on the one hand, the kernel can be updated more easily, but on the other hand there may in practice be a lot more unpatchable binary blobs floating around doing important things.

For a more academic project that has many of the same security concepts there's seL4 [2], which has the additional bonus of doing some insanely clever formal verification of the kernelspace code [3]. They have formal proofs that the compiled machine code actually implements the specified of the security model correctly, which is the first of its kind AFAIK. They actually have a set of interactive tutorials for the platform [4], which are a great way to get a feel for how userspace works on a security-focused kernel.

As a disclaimer, I'm not associated with either project, and I'm sure my explanations will be ripped to shreds. My information comes purely from following the space in my free time.

0: https://fuchsia.dev/fuchsia-src/concepts/principles/secure

1: https://en.wikipedia.org/wiki/Capability-based_security

2: https://sel4.systems/

3: https://sel4.systems/Info/FAQ/proof.pml

4: https://docs.sel4.systems/Tutorials/

From the "Recommendations" section:

> Legislation should address the risks outlined in this report by establishing an appropriate federal prudential framework for payment stablecoin arrangements.29 In particular, with respect to stablecoin issuers, legislation should provide for supervision on a consolidated basis; prudential standards; and, potentially, access to appropriate components of the federal safety net. To accomplish these objectives, legislation should limit stablecoin issuance, and related activities of redemption and maintenance of reserve assets, to entities that are insured depository institutions.

> The standards to which these [insured depository] institutions are subject include capital and liquidity standards that are designed to address safety and soundness and, for the largest banking organizations, also include enhanced prudential standards that address financial stability concerns. Under the Federal Deposit Insurance Act, insured depository institutions also are subject to a special resolution regime that enables the orderly resolution of failed insured depository institutions by, among other mechanisms, protecting customers’ insured deposits, and according priority to deposit claims over those of general creditors, and limits any potential negative systemic impacts in the event of bank failure.

I suspect that we're going to very quickly (by legislative standards) find out which stablecoins are backed by real currency and which are "backed by real currency." I'm betting short-term there'll be some issues with liquidity, especially on smaller exchanges. But longer-term, having the gaps filled in by stabler stablecoins can't hurt.

For what it's worth, it appears a C++ version [0] of that binary search algorithm with Clang 13 requires 9.45 cycles [1]. The clang++-generated ASM is quite similar to the rustc-generated ASM in the article. Not sure what accounts for the difference from the C++ implementations the author was comparing against.

Regardless, it's neat to see the two languages are so close in performance here. I wonder if down the line, the richer information about lifetimes, etc. that Rust provides will allow optimizations beyond those available to C++ -- or if this is already the case.

[0] https://godbolt.org/z/Mj7PWevex [1] https://bit.ly/3CawbUe

Funnily enough, I tried the same thing a while back [0], and got basically the same minimum size (112 bytes in my case). Though it's not nearly as impressive as the article, since all mine did was _exit(42).

I suppose I have no choice but to spend a few hours to try and shave off a couple more bytes now.

[0]: https://github.com/colatkinson/tiny_x64

Exactly that: https://docs.bazel.build/versions/master/sandboxing.html

There's also (I believe experimental) support for using Docker as a sandbox backend. That ends up being useful if you're using the remote build execution support: you can run a build locally in exactly the same environment it will run on a build farm.

This whole case in general is absolutely crazy. Literally decades of people telling various authorities about Raniere, and nothing. Even the Dalai Lama got duped into supporting Nxivm!

If anyone is interested in this, HBO has a docuseries called "The Vow" out. It focuses on Edmonson's story, as well as on some other people she worked with to get the info out. The whole thing is absolutely nuts -- the rabbit hole just keeps going deeper.

It seems this was considered: https://git-scm.com/docs/hash-function-transition/#_using_ha...

The biggest one of those downsides I think is that the SHA-1 history could be changed out from under you if a new attack was published.

Another awesome resource for BBC Micro/Electron software: https://www.stairwaytohell.com/bbc/index.html

That one is especially cool IMO because it provides archives of the old cassettes in UEF format, which aims to preserve some of the audio properties as well (i.e. phase switches, dead spots, etc.).

Not super practical, but it does let you experience the screaming speed of 1200 baud while the computer makes loud noises at you!

Someone even wrapped it with a JS decoder, so you can assault your eardrums in your browser: https://www.8bitkick.cc/playuef.html

Play Music recently got merged into Youtube Music (formerly Youtube Red).

They kept all the features of Play, like uploading your own library, so honestly the least bad Google product death I've seen so far.

I'm pretty much the demographic described above: on the younger side, and optimized for central location in housing.

I have a fairly small 1BR. I don't really have a proper work environment set up--what's the point of cramming a desk in if I'm going into the office every day? I have no yard, so at the moment fresh air is limited. I work, cook, eat, and sleep within the same three rooms.

That's not even touching on people who paid out the ass to get studios in trendier neighborhoods. Personally, I'd lose my mind.

Contrast this with my parents in the suburbs. It's normally a longer commute, but there's a dedicated office, a back yard, and just generally more breathing room.

I think a lot of this is less WFH-related, and more, y'know, apocalypse-related. I could work from a coffee shop or coworking space. Go to the park. Go out for dinner/drinks in the evening. Hell, I could've gotten a bigger, cheaper place if commute time wasn't an issue.

But for the time being, the sprawl of suburban living seems to have its perks.

IIRC one of Monero's design goals is that it isn't easily GPU/ASIC-mineable, so CPU mining is competitive. It's also designed to be difficult to trace.

Both of these properties make it a relatively safe and profitable avenue for malware authors.

Also known as the "Tortoise and Hare Algorithm!"

https://en.wikipedia.org/wiki/Cycle_detection#Floyd's_Tortoi...

We've been using Google Meet at my work for daily "standups." Typically 4-6 people, lasting 15-30 mins. Been very smooth sailing, even using Firefox. Out of curiosity, what kind of issues were you running into?

AFAICT, minikube requires a full VM, whereas this doesn't seem to. So it should, in theory, be much more lightweight.

I've always wanted to do exactly what you just described! Can you recommend any resources to get started with FPGA design for a software dev?

Your app has literally just given me plans for the evening. Awesome stuff!

A straight hashing algorithm isn't what you want for storing passwords. At a minimum, you want it salted. It's also advisable to include an iteration count so that (a) brute-forcing is harder, and (b) you can tweak just one parameter in the future to deal with hardware speed increases. At this point, you've just reinvented a KDF and should use PBKDF2, scrypt, or whatever the KDF du jour is.

TL;DR storing passwords with SHA512 is bad, storing them with PBKDF2-SHA512 is ok and likely overkill.

Never actually seen it used, but: https://en.cppreference.com/w/cpp/utility/any

This looks incredible. Gives me vibes of old school Runescape, mixed with Minecraft. Plus the performance as you've detailed it sounds like quite a feat! Also very cool to see a project that supports old hardware--I remember being a kid with hand-me-down computers struggling to play even some Flash games.

Gonna give this a play tonight. Rock on, dude!

If you've walked into a bank, hospital, or anywhere using a PoS system, you've interacted with legacy software--in some cases, literally jury-rigged DOS software. Outside of trendy dev circles, legacy software is the name of the game.

Already possible in Windows [0].

[0]: https://docs.microsoft.com/en-us/windows/win32/api/processth...

Unsure if you've seen it before, but I've been using sway [0] as a Wayland-based replacement for i3. Switching the configs took about 15 minutes (and could probably be replaced by a few sed commands). It's been very nice to use all around--snappy, no major issues even with multiple monitors, etc.

[0]: https://github.com/swaywm/sway

This isn't entirely accurate. The hack that they used (writing creds directly into the TCC db instead of using the official dialog) was closed by Apple in High Sierra I believe (might've been Mojave? I can't remember atm). Regardless, now they use the official prompt. Of course, while Apple went to the trouble of SIP protecting the TCC db, they didn't actually fix the API for getting Ax permissions, and it's still a massive pain to get it even remotely right.

As for what they're using accessibility for, I believe the official primary use case is tighter integration with the Office suite (e.g. showing users if anyone else has the doc open). So nothing exactly malicious.

This isn't anything new. Keep in mind that Dropbox was offering sync status icons for years before Apple finally created an official API for doing so. IIRC that was using an even dirtier hack, involving monkey patching Finder at runtime. I'd definitely count that as a useful feature as well, and one that Apple had no interest in supporting until it became a user expectation.

I've got no affiliation with Dropbox, and I can definitely see the concern over the TCC hack. But once you try to do any meaningful integration with macOS, you do begin to sympathize. The official APIs are limited, flaky, and prone to deprecation at a moment's notice (see Quicklook plugins in Catalina for a fresh example). And Apple, despite making it impossible for third parties to innovate in their ecosystem, gets to paint themselves as saints.

Security is paramount, of course, but needlessly restricting how users and developers can use the OS will either lead to even dirtier hacks, or only Apple apps being allowed to do new, interesting things. And I don't particularly like either option.