HN user

puffoflogic

254 karma
Posts0
Comments546
View on HN
No posts found.

Sorry, but using new syntax to accomplish something other languages have as library code is not clever.

When reading zig code you have to stop and think, "wait does this syntax mean zip or direct product?" But when expressed as a function called zip, the meaning is clear.

(Obligatory reminder that zig devs think that sometimes running code inside `if (false)` is a minor bug of no consequence, and after all what are the real motives of anyone pointing it out, eh?)

Obvious advertisement is obvious.

KSP2 is universally regarded as an unmitigated disaster. We are at 3 years after the original release date (for the full game) and all that has been released is a fundamentally broken "Early Access" release. It is a rocket building game, and rocket physics are broken. The only things that work in the game are the bits useful for making pretty screenshots or short videos, for advertising purposes.

Anyways, actual reviewers have been saying that the game's UX choices make actually getting to bodies other than Kerbin harder in KSP2 than KSP1, especially for newcomers. For example, TWR information is missing, intercept information is missing, apsis information can't be viewed while editing maneuvers, and delta-v information is alternately missing or wrong. These are all fundamentals which should be present even in an EA release, and while they are things KSP1 experts can work around, they make it impossible for newcomers to accomplish anything.

This game will never (truly) leave EA; it will be killed.

Freedom of speech isn't freedom of consequences.

Freedom from consequences is the only possible thing freedom of speech could be, other than not having your mouth sewn shut.

What you meant to say was, what we value is freedom of speech from government consequences, not private actors. And that is a value judgement, not definitional. The incorrect statement you used is spread by people trying to hide the former as the latter.

I would have thought anything that can radiate heat slowly and consistently would by necessity also absorb heat slowly and consistently

Aside from the technological measures mentioned in other replies, I'm not sure this follows. Thermal energy transfer is proportional to the temperature difference. So a high thermal mass storage can absorb energy quickly from a high temperature source, experience a small change in temperature, then expel the heat slowly into a sink slightly cooler than itself. That is a gross oversimplification but it at least it shows that the effect is not too surprising.

I've read several articles from the Atlantic in the past few days which suggest it is a right-wing publication. (E.g., this one is about reducing government size and citing the far-right IJ organization.) This is odd because I hadn't really identified it that way before. Anyone have info on why this sudden change?

You cite yet another article which you clearly don't understand, and whose authors have questionable understanding themselves.

This article cites CVEs of a certain type, which were especially popular in the 2021 timeframe. These CVEs do not correspond to real vulnerabilities in real executables. Rather, they are reporting instances of rust programs violating the strictest possible interpretation of the rules of the rust language. For comparison, quite literally every single C program ever written would have to receive a CVE if C were judged by the same rules, because it isn't possible to write a C program which conforms to the standard as strictly as these Rust CVEs were requiring. CVEs of this nature are a bit of a meme in the rust community now, and no one takes them seriously as vulnerabilities. They are reporting ordinary, non-vulnerability bugs and should have been reported to issue trackers.

The whole discussion about layout order is completely irrelevant. When RE'ing unknown code you don't know the corresponding source anyways, so the one-to-many correspondence of source to layout is irrelevant. You are given the layout. You can always write a repr(C) which corresponds to it if you're trying to produce reversed source. This is no different than not knowing the original names of variables and having to supply your own.

The next objection is literally that rust does not use null-terminates strings, except the authors are so far out of their depth that they don't even identify this obvious root cause of their tools failing. Again, this has absolutely nothing to do with the reversibility of rust programs, except perhaps preventing some apparent script kiddies from figuring it out.

The authors do manage to struggle to shore, as it were, by the end of the article, and somehow they end up correctly identifying their tools and understanding and the root cause of their troubles, not Rust. I take it you didn't make it that far when you read it?

Why not also be sure to mention what OS was used for the build, and what linker, and what file format, and what model of computer was used, and what its default ui language was set to? What is so special about programming language used that sets it apart from those other factors that could be mentioned?

One of the things which most fascinated me about the Mill architecture (don't bother checking for updates, it's as vaporware as ever) was the ability to pass arbitrary memory ranges across "process"/security boundaries, rather than being stuck with page granularity and requiring complex OS assistance. This would make zero-copy much easier to accomplish. Page-based memory protection is holding us back: pages are a clever solution to, well, paging to disk, but a remarkably terrible solution for everything else they're used for.

We should be able to assume that the data we want exists in main memory without having to keep telling the system to load more of it.

This already exists in POSIX. It's called mmap, and approximately no one uses it. Maybe the article should have explored why, and suggested how to solve that problem, instead of insisting we must throw everything away and this will magically solve our problems.

Is_email() 3 years ago

That's absurd, you're just asking for failure unless you load it from a dedicated high,-availability microservice built on a dedicated cloud non-relational key-value store.

Is_email() 3 years ago
    define('ISEMAIL_STRING_AT'  , '@');
    define('ISEMAIL_STRING_BACKSLASH' , '\\');
    define('ISEMAIL_STRING_DOT'  , '.');
    define('ISEMAIL_STRING_DQUOTE'  , '"');
    define('ISEMAIL_STRING_OPENPARENTHESIS' , '(');
    define('ISEMAIL_STRING_CLOSEPARENTHESIS', ')');
I find it hard to believe people seriously still do this. This is satire, right?

Why does the map (appear to) use exclusively endonyms?

Is this a new style requirement for socially correct behavior?

For what it's worth, I had the same reaction upon reading this paragraph. It seems there are HN commenters who understand software design and those who do not.

To be fair to the other commenters, it's conceivable that the practical difference between the current unsound architecture and a sound replacement might come down to to some small defect. But an attempt to fix the problem by fixing just the defect, even some kind of RCA process on it, will fail if the architecture itself is not fixed, and that requires a change in attitudes and understanding by the devs responsible for the system, not just a software change. That is where the real flaw lies. But some people don't believe that it's possible for the flaw to be in these places, outside the code. All the RCAs in the world can't help them.

peanut oil doesn't have the allergen that triggers most peanut allergies

Facts like that are completely irrelevant before a judge and jury, so their position is understandable and probably for the best (for them).

When Rust hurts 3 years ago

Rust's "fearless concurrency" always referred to traditional thread-based concurrency, which works very well for 99% of usecases. Async is something that was bolted on to the language long afterwards by folks coming from the JS/Node community who didn't understand threads or the value of fearless concurrency.