NobodyNada · HackerTrans

NobodyNada

3,551 karmajoined il y a 7 ans

Submissions

Greg KH: Untrusted data in Linux – How Rust is going to save us [video]

youtube.com

2 pointsby NobodyNadail y a 2 mois0 comments

Binary patching live audio software to fix a show-stopping bug

jonathankeller.net

2 pointsby NobodyNadail y a 8 mois0 comments

Rust 1.88.0

blog.rust-lang.org

24 pointsby NobodyNadal’année dernière0 comments

About the security content of Logic Pro X 10.7.3

support.apple.com

1 pointsby NobodyNadail y a 4 ans0 comments

Russia blows up a satellite, creating a dangerous debris cloud in space

theverge.com

17 pointsby NobodyNadail y a 5 ans6 comments

Apple Event [live]

apple.com

2 pointsby NobodyNadail y a 5 ans0 comments

Something like a fireball/meteor blazes over Oregon skies

katu.com

3 pointsby NobodyNadail y a 5 ans0 comments

AppTrackingTransparency Requirement Update

developer.apple.com

1 pointsby NobodyNadail y a 6 ans0 comments

Swift System Is Now Open Source

swift.org

500 pointsby NobodyNadail y a 6 ans328 comments

Swift 5.3 Released

swift.org

6 pointsby NobodyNadail y a 6 ans0 comments

Swift AWS Lambda Runtime

swift.org

223 pointsby NobodyNadail y a 6 ans79 comments

Stack Overflow has fired two longtime Community Managers

meta.stackexchange.com

12 pointsby NobodyNadail y a 7 ans2 comments

comments

il y a 3 joursdiscuss

> what's difficult about unsafe rust, which is how unergonomic pointers are. Like why do I need to use `addr_of_mut!`?

Things are slowly getting better here! '&raw'/'&raw mut' reference operators were stabilized a couple years ago.

Another ergonomic improvement in the pipeline is a better way to access fields behind pointers, something like C's -> operator. This is taking some time to design because there are things other than raw pointers that would benefit from a generalized field projection mechanism, like Pin, NonNull, and (potentially user-defined) smart pointer types.

il y a 5 joursdiscuss

Not the parent, but: I strongly dislike this framing of "Fil-C is better than Rust" or "Rust is better than Fil-C". This is apples-to-oranges; users will almost never be comparison-shopping between the two because they address almost entirely different problems.

There are roughly two categories of Rust user:

1. People who are using Rust for application development. Most of these users write zero unsafe blocks in their careers. For these users, "memory safety" was probably not a strong reason to pick Rust, because there are a wealth of other memory-safe application development languages out there.

2. People who are using Rust for systems programming (i.e. programming under resource or environment constraints). These users may write unsafe for performance reasons, or to do things like hardware MMIO; and they're using Rust over C/C++ either for security or just because the tooling is nicer.

The first category of user is unlikely to consider C for application development in this decade; they're going to be comparing Rust against Go or Java or Node.js. Fil-C solves the security problem of memory safety, but it does not free the developer from the difficulty of having to manually write memory-safe C code; their program will just crash if they get it wrong.

The second category of user cannot use Fil-C because of its performance overhead, runtime requirements and/or lack of escape hatches for MMIO/FFI.

Where Fil-C does shine is for legacy application software written in C. Here, it's a free lunch: a way to harden the massive amount of existing software without an expensive rewrite. I would love to see distros shipping pizlonated coreutils, ffmpeg, systemd, curl, sudo, postgres, etc., anything that has a big attack surface, but does not need to be memory-unsafe.

This is a problem I care about a lot, and your work here is truly a monumental advancement in the field. Comparisons to Rust sell it short by inviting endless debate on problems largely tangential to Fil-C.

il y a 5 joursdiscuss

Exactly, my point is that the compiler and runtime are the "unsafe" portions of Fil-C, and that Fil-C and (safe) Rust are equivalent in this regard.

il y a 5 joursdiscuss

Machine code is unsafe, so any memory-safe language must necessarily be built on some unsafe code somewhere. Safety is always conditional on the underlying unsafe implementation having no bugs.

With Fil-C, the "unsafe blocks" live entirely within the compiler and runtime. With Rust, the unsafe foundation is the Rust compiler and standard library, as well as any unsafe code within your application or dependencies.

So either way you're in the same situation of relying on the correctness of the unsafe code you depend on. But there are two major differences:

- Unsafe code can be written in Rust, instead of inside the compiler. This is much easier to write and to review for correctness.

- People other than Fil are allowed to write unsafe Rust. This is what Fil's point is about, and yes, it allows you to opt-in to increasing your attack surface by trusting unsafe code written by yourself or your dependents. Rust allows the user to choose where they draw the trust boundary, and Fil-C does not.

It's true that Fil is probably better than I am at writing unsafe code. So "Fil-C is safer than Rust" is true in that sense. But Fil-C is certainly not safer than safe Rust. And sure, you can't run all the Rust code in the world if you compile with '--deny unsafe_code'; but Fil-C can't run all the C code in the world either. Unsafe Rust is rarely needed, mostly only if you want to do pointer crimes or FFI, and Fil-C doesn't support a lot of (perfectly legal) pointer crimes and FFI either.

il y a 6 joursdiscuss

Honda's recent hybrids (CR-V, Civic, Accord) are like this too. Mostly series, but the engine can directly drive the wheels via a single overdrive gear for better cruising efficiency.

il y a 15 joursdiscuss

> I think "storing deltas" based on seed is largely how Minecraft saves the level already

This is not the case, level data is stored in full. One reason for this is that level generation is pretty slow (compare the time it takes to create a new world vs. load an existing one); another reason is that it changes between versions.

il y a 26 joursdiscuss

> Beato doesn't do much hour-long unscripted talking to the camera. Those videos are typically only about 10 minutes long.

The videos are heavily edited with many cuts. So, I'd guess the production process is "have him talk for an hour, then edit it down to a 10 minute YouTube video".

> In any event, Rick Beato seems like a normal human being, albeit a somewhat goofy dad-rock oldie. 12Tone comes across as an aspie weirdo. I'd rather have more of the former.

And that's...kind of the point I'm making? The amount of effort put into the content of Beato's videos is quite low, with probably a couple hours at most of time put into research, coming up with talking points, and recording. But a lot of effort is spent on production, in order to make content that feels relatable and punchy and palatable to a mass market. It's junk food, and junk food sells well.

il y a 26 joursdiscuss

> "The Real Reason Music is Getting Worse"

As a musician myself, and as someone who enjoys watching music and music theory content on YouTube, I can't stand watching Rick Beato because of stuff like this. There certainly are valid criticisms to be made against the music industry, but those videos are like 90% ridiculous cherry-picked comparisons and vague, superficial justifications. It's low-quality nostalgia-driven engagement bait that's optimizing for clicks and comments.

I really like this video by 12tone addressing Beato's schtick about modern music [0]. 12tone is an example of someone who I consider produces much higher quality content than Beato, and obviously puts a ton of time and effort into the videos (writing scripts, drawing the visuals, recording and editing, and making moderately-clickbaity titles and thumbnails). But I'd guess it's probably a one-person operation.

In comparison, Beato's channel strikes me as low-effort content (pick a topic and spend an hour talking unscripted in front of a camera) with a ton of money spent on production, editing, and algorithm hyper-optimization to maximize ROI. It's such a straightforward case of something that would not exist without YouTube's monetization system that it's rather ironic for the parent to use it as an example otherwise.

[0]: https://www.youtube.com/watch?v=tODG4Xt45bU

le mois dernierdiscuss

The PPU (and variants of it) was used in quite a few arcade machines, in addition to the NES.

I don't know if there were any actual machines that used dual PPUs, but the functionality was likely intended for creating an arcade machine with dual-layer background graphics.

le mois dernierdiscuss

It is also heavily associated with humans writing about things which bear load (in an xkcd #2347 sense) :)

le mois dernierdiscuss

10 years ago, GitHub had a far better reputation and the Rust ecosystem was much smaller and less load-bearing, so "what if someone doesn't have a GitHub account" was a theoretical concern for most people. So the issue was a low-priority backlog item that everyone agreed would be nice-to-have but there weren't enough people willing to volunteer their time to it over more important and more impactful work.

Obviously, the situation has changed in recent years, so it's now considered a much higher priority by many people and some of them are actively working on it. But it's a lot of work to be done by volunteers, so it takes time.

That's the reality of open-source projects: things get done when they are important enough to motivate someone to either fund it or work on in their free time, not according to idyllic roadmaps and schedules.

le mois dernierdiscuss

> Using "if" or "unless", whichever is more appropriate, is far more readable than "guard".

How is a different (and longer) keyword "far more readable"? That's just a matter of preference and familiarity. The reason for choosing a different keyword is that it's not quite equivalent to an unless as the {} block must exit the surrounding scope. You read it like an assert statement with a custom handler.

> Moreover, there are many languages where an assignment or an initialization can appear in any place where an expression can appear. Such general rules are always better than special rules like allowing new bindings in a "guard", but not in an "if".

You can introduce bindings in an if too. The special thing about guard is that you can introduce a binding which is valid for the remainder of the scope outside the {} block (where the condition is true) but not inside (where the condition is false).

le mois dernierdiscuss

guard is an inverted if statement, with the additional requirement that the branch must exit the parent scope. It's useful sometimes for readability, particularly for avoiding the "pyramid of doom" when you have a lot of preconditions that need to be checked:

    if fooOK 
        if barOK {
            if bazOK {
                // do something
            }
        }
    }

can be written as:

    guard fooOK else { return }
    guard barOK else { return }
    guard bazOK else { return }
    // do something

Obviously there are other options (like writing a negated if), but sometimes guard is more readable. It's a style thing.

The more important use case for guard is that 'guard let' statements can pattern-match and introduce bindings that are valid for the rest of the scope:

    guard let foo = someOptional else { return }
    print(foo);

This is useful enough that Rust copied it in the form of 'let ... else {}' statements (but did not bring over boolean guard statements).

le mois dernierdiscuss

Most people without absolute pitch have some level of "pitch memory", but it's not comprehensive or reliable. For instance, if you ask people to sing a pop song, they're significantly more likely than chance to sing it in the original key.

I know the Super Mario Bros. theme starts on an E, so I can identify an unknown pitch by recalling that theme and comparing using relative pitch. But that's quite a slow and unintuitive process, and it's easy to make a mistake. People with absolute pitch just hear the pitch without having to "recall" a reference note to compare to like that.

le mois dernierdiscuss

I'm a musician who doesn't have absolute pitch, but does have very strong relative pitch. My understanding is that perfect pitch is neat party trick, but actually a hindrance instead of a help in most musical circumstances. Relative pitch, on the other hand, is incredibly useful (and fortunately you can train and develop it later in life).

Because most people don't have perfect pitch, (Western) music is built on the relationships between pitches rather than the absolute pitches. So with absolute pitch, you can play something by ear; with relative pitch, you can play something by ear in any key.

Learning to think of the notes you're playing relatively instead of absolutely is already a difficult leap for most musicians, and my understanding (though I don't have absolute pitch so I can't compare from experience) is that absolute pitch makes this skill significantly harder to acquire, since you have to retrain your ear in addition to your hands.

If I were offered a choice to trade my sense of relative pitch for absolute pitch, I most certainly would not take it. I know well the feeling of incongruity when my muscle memory is stuck in the wrong key, and absolute pitch would mean I'm stuck there all the time instead of being just able to shake my head, focus on the new key, and clear my mind of the old.

le mois dernierdiscuss

The engineer who wants the build to be reproducible and the engineer who wants to have the build time in the compiled binary may not be the same person.

le mois dernierdiscuss

The reason for this is to ensure stack overflows are detected. The OS places a guard page above the top of the stack, which will cause a segfault if accessed. That way stack overflows are guaranteed to crash rather than stomping on valid memory that belongs to something else. However, if a stack frame is larger than a page (say, because it includes a large buffer), then it is possible for the program to "jump over" the guard page and access memory beyond.

In order to protect against this, the compiler inserts some dummy reads or writes as needed to ensure every page is touched in order from bottom to top. This ensures the guard page is hit before the application has a chance to write to memory beyond it.

Here's an example: https://godbolt.org/z/oTbzTczM6

il y a 2 moisdiscuss

The headphones are from AIAIAI: https://aiaiai.audio/headphones/tma-2-studio-wireless

Loopback looks nice, but I prefer to keep the routing entirely within my DAW (or my interface where possible) to keep latency to a minimum, particularly since I'm already using wireless headphones that add 10ms latency.

Another mitigation I now have is to use an aggregate device that has BlackHole on the first two channels rather than the main outputs. That way, if I accidentally start playing audio, it gets harmlessly sent to the void; and it also means I can easily capture and forward it in my DAW if I actually want to play PC audio (for example, listening to a recording during a rehearsal).

il y a 2 moisdiscuss

I needed something like this a few months ago. I use my MacBook to run my (musical) keyboard rig for live performances, and use low-latency wireless headphones for monitoring. The headphones have a transmitter dongle that plugs into my laptop, and the dongle sends a "play/pause" command if I press a button on my headphones...causing Music to launch and begin playing audio out of my default output device. It doesn't even care whether my headphone transmitter is selected as the default output device; in a complex multi-device setup, I can press a button on my headphones and it will happily play audio out of some other device.

This is problematic because if I were to accidentally hit the button in the middle of a set, and it decides to default to whatever interface is connected to the P.A. system, then now I've just started blasting some random song at full volume to everyone in the venue.

(It's not an immediate problem for me anymore because I've reworked my hardware setup such that the dongle connects through my audio interface rather than directly to my laptop, meaning my laptop no longer receives "play/pause" commands from it. There were additional reasons for this rework, but preventing this misbehavior was absolutely part of the consideration.)

It's absurd that a premium device marketed to creative professionals has unconfigurable behavior like this which is so unacceptable for a live show.

il y a 2 moisdiscuss

(Not the parent, but I'm faceblind as well)

The interaction described goes like this:

"Hi there, I'm ABC, nice to meet you, what's your name"

"...Huh? I'm XYZ. We've met before."

"Oh right...sorry, I promise I remember you! We knew each other from there, and we've worked on this and that together, and etc. etc. etc. I'm just terrible with faces, I'm so sorry!"

It's not "you know things about them without recognizing them"; it's "you don't recognize them at first, it gets awkward, and so you recite facts about them prove that you didn't forget who they were"